April 2004 - U-Boot

RE: [U-Boot-Users] U-Boot/Kermit Problem
by Daren Hayward 29 Apr '04

29 Apr '04

I had a similar problem I ended up getting it to work with using the following SET PREFIXING ALL SET PARITY NONE SET CARRIER-WATCH OFF also ensure there is no handshaking see the kermit manual for more information. I have placed the above commands in ~/.kermrc so they are picked up by minicom when it calls kermit. btw they recommend not using minicom for serial transfers, I have used U-boot v 1.1.1 with minicom serial file transfer with no problems though. Daren From: Ashish R Dhawane <ashish(a)cdotb.ernet.in> To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] U-Boot/Kermit Problem Date: Thu, 29 Apr 2004 11:58:28 +0500 (GMT+0500) I am facing a problem in loading a binary file from minicom. Whenver I try to load, it is going in an infinite loop. => loadb 100000 ## Ready for binary (kermit) download to 0x00100000 at 9600 bps... I configured kermit as told in the DULG/SystemSetup Manual.... Only change I made is set speed 9600 instead of 115200 I am getting stuck here. After going through the u-boot source code .... The calling sequence is .... -load_serial_bin -k_recv Inside k_recv the code where I stucked up here is ... ----------------------------ACTUAL CODE----------------------------------- /* get a packet */ /* wait for the starting character or ^C */ for (;;) { switch (serial_getc ()) { case START_CHAR: /* start packet */ goto START; case ETX_CHAR: /* ^C waiting for packet*/ return (0); default: ; } } ----------------------------ACTUAL CODE UP TO HERE------------------------ I think it continiously in the for loop. When I press control-C then it will come comeout saying .... ## Total Size = 0x00000000 = 0 Bytes ## Start Addr = 0x00100000 Can anyabody help me why it is happening ? Any help will be appreciated. -regards, -Ashish ########################################################################### Ashish R Dhawane Research Engineer W-CDMA Group (3G RAN) Contacts: --------- Tel(O) :+91-80-2282168 (Direct Line) Tel(O/Lab) :+91-80-2263399 X 329 Fax(O) :+91-80-2282168 Mobile :98455 36814 E-Mail(s) :ashishdhawane@yahoo.com, ashish(a)cyberspace.org Surface Address (O): Surface Address (R): -------------------- -------------------- Centre for Development of Telematics, #50, Ground Floor, 12th Cross, 71/1, Sneha Complex, Ayyappa Block, Manorayan Palya, Millers Road, Sultan Palya Main Road, Bangalore-560052, RT Nagar Post,Bangalore-560032, Karnataka, India. Karnataka, India. ########################################################################### ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

[U-Boot-Users] i368 / amd Sc520 Uboot
by Wolfgang Kanovsky 28 Apr '04

28 Apr '04

Hi All im trying to use U-boot for i386/AMDSC520 implemetation ... Fixed a lot of files .. last i had to worry with the implemtation of the mkimage and linux - do_bootm implementation I was not able to start a kernel now at all ..system hangs .. know reason why ..any hints ? suggestions ..or anyone here how has fixed it ? any help would be very nice !! best regards Wolfgang k. @ Wolfgang Denk : Hallo ! -- wer pflegt eigentlich den i368 code scheint sein jahren nix mehr passiert zu sein und im vergleich zum PPC um jahrhunderte zurück zu liegen :-(( geschweiged das der code so wie er im cvs is auch nur annähernd starten würde ... ---------------------------------------------------------------------------- int enter_realmode(u16 seg, u16 off, struct pt_regs *in, struct pt_regs *out) { printf("before bios_setup...\n"); /* setup out thin bios emulation */ if (bios_setup()) { return -1; } printf("before realmode_setup...\n"); if (realmode_setup()) { return -1; } printf("after bios_setup...\n"); in->eip = off; in->xcs = seg; if (3>(in->esp & 0xffff)) { printf("Warning: entering realmode with sp < 4 will fail\n"); } printf("before memcpy...\n"); memcpy(REALMODE_MAILBOX, in, sizeof(struct pt_regs)); asm("wbinvd\n"); printf("after memcpy...\n"); __asm__ volatile ( "lcall $0x20,%0\n" : : "i" (&realmode_enter) ); asm("wbinvd\n"); memcpy(out, REALMODE_MAILBOX, sizeof(struct pt_regs)); return out->eax; schould exec of teh kernel start here?????????????????????? } LOG: U-Boot 1.0.2 (Apr 28 2004 - 00:01:51) ######################################################### # Adopted for HOPF AMD SC520 Embbeded BOARD # ######################################################### U-Boot code: 08FC0000 -> 08FDF349 data: 03F00000 -> 03F017F3 BSS: 03F017F4 -> 03F0BCBF stack: 03F0BCC0 -> 03F13CBF DRAM Configuration: Bank #0: 00000000 64 MB Bank #0: Micron / Intel 28F640J3A Flash: 16 MB FLASH: 16 MB set_irq(): map INTA to IRQ9 00 11 8086 1209 0200 09 In: serial Out: serial Err: serial Net: i82559#0 ***SC520 hopf BOARD last stage init done*** boot => bootm 8000000 U-Boot Command_code_tabelle: 08FD7C36 -> 08FD80B8 U-Boot Cmd_table_start_search: 08FD7C38 ## Booting image at 08000000 ... Image Name: Hopf Embedded Linux Kernel Image Type: Intel x86 Linux Kernel Image (uncompressed) // fix for i368 mkimage ! Data Size: 752142 Bytes = 734.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK OK No initrd Using boot protocol version 2.03 Linux kernel version 2.4.21-NANO-rthal5 (rac@chicago) #2 Tue Apr 27 19:58:10 CEST 2004 Kernel command line: "console=ttyS0,9600 root=/dev/ram0 rw " Loading bzImage at address 0x00100000 (749070 bytes) ## Transferring control to Linux (at address 00090000) ... Starting kernel ... before bios_setup... before realmode_setup... after bios_setup... before memcpy... after memcpy...

2 1

Re: [U-Boot-Users] Newbie needing help with IBM 440 GX (OCOTEA)
by Daren Hayward 28 Apr '04

28 Apr '04

Thanks to Trevor and Wolfgang. It was the flow control, I believe anyway! I turned it of in the terminal emulator and it didn't work, however after restarting the terminal emulator it started to work! Thanks Daren From: Wolfgang Denk <wd(a)denx.de> To: "Daren Hayward" <daren_hayward(a)hotmail.com> CC: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Newbie needing help with IBM 440 GX (OCOTEA) Date: Tue, 27 Apr 2004 16:09:09 +0200 In message <BAY2-F163f7zeOmVjDd0002c3e2(a)hotmail.com> you wrote: > > BEDBUG:ready > => > > this is where my problems start! I have no response to anything typed on the > keyboard Did you try the obvious, like disabling flow control in your terminal emulation program, or enabling it if it was off? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de An Elephant is a mouse with an Operating System. - Knuth ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

1 0

RE: [U-Boot-Users] [RFC] NAND Flash
by Woodruff, Richard 27 Apr '04

27 Apr '04

Hello Pantelis, I recently used that code a quite a bit...I probably have a few changes which I probably should have sent back in...there were some problems with some operations to the oob, and one bit about bad blocks which we enhanced. I'll send you version of the code for you to compare against later. > I'm asking for any people currently working with NAND to comment > on the following points: > > 1. Do you read and write the NAND at arbitrary offsets? > That means not in page boundaries. No not usually. We generally only used it for catastrophic recovery. In that case we would write a file system image out. Because it is fairly slow, I usually had a separate kernel partition. The board I used to use had a NOR u-boot. At reset with would jffs2 scan the first partition and recover the kernel (which had mtd+nand) built in. It would load and start this kernel. This kernel mounted a read only root system partition in NAND, and a r/w user partition. Updates were expected to happen at the kernel level...if they failed badly, you could send an Image to u-boot which could then re-burn the entire partitions. In newer processors which TI is doing, we actually can drop the NOR all together. The processor's have hardware acceleration and enough microcode in mask rom to boot from a single external NAND. U-boot will be supported in these systems. > 2. Do you use the NAND boot command? It can be replaced by a copy and > bootm sequence. Only for development. It's a bit more quick to burn in a raw image, but also not very safe. I think some manufactures may guarantee that some number of the first blocks are good. If you don't write them very much you are probably pretty safe. > 3. Do you use it as a raw device without employing ECC? Do you > understand the implications? Raw only for development. > > 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB > placement of ECC and status bits? We used JFFS2 and NAND. Actually, we paid Woodhouse to get JFFS2+NAND support up to par. Current snapshots on his CVS seem pretty safe. > 5. What kind of bad block management options would you like? I'm thinking > of implementing a bad block detection mechanism which would erase and > test the whole chip for any bad blocks. > Another command could also utilise ECC to detect borderline working > pages and relocate them to avoid a permanent failure. > > Awaiting your input... > > Regards > > Pantelis > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 2

[U-Boot-Users] Newbie needing help with IBM 440 GX (OCOTEA)
by Daren Hayward 27 Apr '04

27 Apr '04

Hi, I recently downloaded and setup u-boot, to create the u-boot.bin file I used did the following make distclean make OCOTEA_config make all I then updated the flash, and booted and I get the following ... U-Boot 1.1.1 (Apr 26 2004 - 15:15:40) IBM PowerPC 440 GX Rev. B Board: IBM 440GX Evaluation Board VCO: 1066 MHz CPU: 533 MHz PLB: 152 MHz OPB: 76 MHz EPB: 76 MHz I2C: ready DRAM: I2c read: failed 4 I2c read: failed 4 256 MB FLASH: 5 MB *** Warning - bad CRC, using default environment PCI: Bus Dev VenId DevId Class Int 00 01 1000 0020 0100 00 00 01 1000 0020 0100 00 00 03 100b 0033 0000 00 In: serial Out: serial Err: serial KGDB: kgdb ready ready Net: ppc_440x_eth0 BEDBUG:ready => this is where my problems start! I have no response to anything typed on the keyboard any help would be appreciated, I hope this has not been covered elsewhere, but I could not find it. Thanks in advance Daren _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

RE: [U-Boot-Users] [RFC] NAND Flash
by Dave Ellis 27 Apr '04

27 Apr '04

Pantelis Antoniou wrote: > The big problem with the code as it is its its tendancy not to > account properly for errors which are not only probable but > certain during the life of the device. > > For example the current code cannot boot reliably from NAND > and the read and write routines are also unreliable. > > It's basic assumption made that you can read/write from the NAND > at any position is false. This is impossible because of > the bad blocks that may force you to skip a bad sector. The nand boot looks broken to me. The .jffs2 commands work well for me for booting from a jffs2 partition. > I'm currently in the process of rewritting to actually make it > work reliably. > > I can keep backwards compatibility with the old code but > you can only use it at your own risk. It definitely could use a rewrite. It looks like it was ported from a very old version of mtd. Please let's keep the .jffs2 options for jffs2, so we can add optimizations such as skipping to the end of an empty erase block without breaking other uses. > I'm asking for any people currently working with NAND to comment > on the following points: > > 1. Do you read and write the NAND at arbitrary offsets? > That means not in page boundaries. No. I read an entire JFFS2 partition, or write a JFFS2 image, but only on page boundaries. > 2. Do you use the NAND boot command? It can be replaced by a copy and > bootm sequence. No. > 3. Do you use it as a raw device without employing ECC? Do you > understand the implications? No, use ECC and JFFS2. > 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB > placement of ECC and status bits? JFFS2 > 5. What kind of bad block management options would you like? I'm thinking > of implementing a bad block detection mechanism which would erase and > test the whole chip for any bad blocks. > Another command could also utilise ECC to detect borderline working > pages and relocate them to avoid a permanent failure. If the factory or linux/jffs2/mtd have marked a block bad it shouldn't be erased. There is no reliable way to find them again without factory tests, and I think the manufacturers say that erasing a factory marked bad block can make the good blocks unreliable. I want jffs2 to handle any new bad blocks. Dave Ellis ~~~~~~~~~~~~~~~~~~~~~~~~~~ SIXNET - "Leading the Industrial Ethernet Revolution" 331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA Tel +1 (518) 877-5173 Fax +1 (518) 877-8346 Email me at: dge(a)sixnetio.com Detailed product info: www.sixnetio.com ~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: [U-Boot-Users] [RFC] NAND Flash
by Woodruff, Richard 27 Apr '04

27 Apr '04

> I hope you don't solder your chips on the board, cause bad blocks can be > present in pristine chips fresh from the factory. > This will NOT work, since a bad block anywhere in the range that you use > means that you must replace the chip. > Bad blocks can in practice be a bit harder to get then one might think. In say ... 500 different samples which passed my desk in the last three years none of them actually had bad blocks. They could have of coarse. We simulated bad blocks. It is a real problem. Regards, Richard W.

2 1

RE: [U-Boot-Users] [RFC] NAND Flash
by VanBaren, Gerald (AGRE) 27 Apr '04

27 Apr '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Pantelis > Antoniou > Sent: Tuesday, April 27, 2004 3:45 AM > To: Peter Billek (VI/SEA) > Cc: U-Boot Users > Subject: Re: [U-Boot-Users] [RFC] NAND Flash > > > Peter Billek (VI/SEA) wrote: > > >We are in the progress of starting to implement u-boot and > will need NAND support as well. [snip] > >AS or the bad block cheeking, I would rather go for the > relocation implementation rather than the erasing the complete chip. > > > > > Me too, but it's kinda tricky... The Toshiba NAND flash we use comes from the factory with the bad blocks already marked (they may grow more bad blocks, but the initial ones are identified during manufacturing testing). If you erase the chip without saving the information first, you lose that valuable information. You should check with your supplier to see how they handle it. gvb ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

RE: [U-Boot-Users] [RFC] NAND Flash
by Peter Billek (VI/SEA) 27 Apr '04

27 Apr '04

We are in the progress of starting to implement u-boot and will need NAND support as well. As it looks at the moment we will access the NAND flash not in page boundaries, but rather with arbitrary offsets. At the moment we are using something similar to the boot command with is still a adaptation from former armboot. We don't use ECC and also no FS, rather fixed addresses. However this has to change in the future, but for the moment we are just prototyping. AS or the bad block cheeking, I would rather go for the relocation implementation rather than the erasing the complete chip. I am looking forward to see how your work progresses and might commit to it in the future as well if I can. greetings Peter Billek Board Level Design, Realtime SW Local Design Center VIE Ericsson Enterprise GmbH mailto:peter.billek@ericsson.com -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Pantelis Antoniou Sent: Dienstag, 27. April 2004 09:08 To: Wolfgang Denk; U-Boot Users Subject: [U-Boot-Users] [RFC] NAND Flash Hello there. As you remember earlier I have sent a small patch for the NAND portion of u-boot. This forced me to really take a hard look at the code and really evaluate it. The big problem with the code as it is its its tendancy not to account properly for errors which are not only probable but certain during the life of the device. For example the current code cannot boot reliably from NAND and the read and write routines are also unreliable. It's basic assumption made that you can read/write from the NAND at any position is false. This is impossible because of the bad blocks that may force you to skip a bad sector. I'm currently in the process of rewritting to actually make it work reliably. I can keep backwards compatibility with the old code but you can only use it at your own risk. I'm asking for any people currently working with NAND to comment on the following points: 1. Do you read and write the NAND at arbitrary offsets? That means not in page boundaries. 2. Do you use the NAND boot command? It can be replaced by a copy and bootm sequence. 3. Do you use it as a raw device without employing ECC? Do you understand the implications? 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB placement of ECC and status bits? 5. What kind of bad block management options would you like? I'm thinking of implementing a bad block detection mechanism which would erase and test the whole chip for any bad blocks. Another command could also utilise ECC to detect borderline working pages and relocate them to avoid a permanent failure. Awaiting your input... Regards Pantelis ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
by Kumar Gala 26 Apr '04

26 Apr '04

I was wondering if there where an examples in the current u-boot source tree in which CONFIG_SYS_CLK_FREQ was determined dynamically. I have a system in which I can read a config register on the board to let me know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz. I was hoping to have the 16550 uart (and anything else) that needed CONFIG_SYS_CLK_FREQ grab it from a variable instead. This is on an MPC85xx platform system. thanks - Kumar

4 16