September 2006 - U-Boot

Re: [U-Boot-Users] [DNX#2006091642000025] PHgslARMA
by U-Boot patch tracking system 16 Sep '06

16 Sep '06

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2006091642000025]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

Re: [U-Boot-Users] [DNX#2006091642000025] PHgslARMA
by DENX Support System 16 Sep '06

16 Sep '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006091642000025] was created: <snip> > Hi > > QUIT O y VERP i AYIN x G FOR Y l OUR PH f AR p MAC p Y > > S j AV q E up q to 5 w 0 % wi o th http://www.bertagunhuijins.com </snip> Your U-Boot support team

1 0

[U-Boot-Users] keeping build date and time up to date
by David Byron 16 Sep '06

16 Sep '06

I was looking at how U-Boot gets the date and time in the version string and I noticed that it doesn't get updated for each build. I'm using an arm-based board, and the code for building the version_string variable is in lib_arm/board.c. In other words, the date and time only get updated when that file (or anything it depends on) changes. There's similar code in other lib*/board.c files. I'm attaching a patch that builds the entire version string (including date and time) just before linking U-Boot so it's always up to date. Key features of the patch are: 1. Makefile generates version info in version_autogenerated.c, not include/version_autogenerated.h. I did this to avoid recompiling everything that depends on version.h since it changes every time. 2. There's no separate version recipe in Makefile since that caused a relink every time. 3. version.h now is C specific -- assembly files can no longer include it. 4. I deal with CONFIG_IDENT_STRING with a small program tools/identstr that I run from Makefile. I did this to avoid generating version_string at runtime with either a fixed size buffer that might not be big enough, or with malloc. This patch is incomplete though. I'm sending it because I'm curious if this is interesting to other people (and they agree with the approach) and because I have some questions about how to proceed. They are: - Lots of .S files include version.h but don't seem like they need to. I believe I can take them out without changing behavior. - Lots of .S files have code like this: .globl version_string version_string: .ascii U_BOOT_VERSION .ascii " (", __DATE__, " - ", __TIME__, ")" .ascii CONFIG_IDENT_STRING, "\0" I believe I can take these out as well. I could use confirmation on both of these items. - The blackfin board does something special with the version string. I'm sure I can come up with something equivalent but I wanted to get the above worked out first. Thanks for your input. -DB

2 2

[U-Boot-Users] PPC Discontiguous Memory Space
by jbahr 16 Sep '06

16 Sep '06

We have a client building a PPC8548-based product who insists that we allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in the 36-bit address space. It doesn't look like U-Boot's bd_info structure allows for that, and it doesn't look like the Linux init routines (which accesses the passed table) knows how to handle discontiguous memory either (as opposed to X86 Linux, which can accept an E820 table). It looks like Linux cleans out the TLB's pretty quickly, so it wouldn't know the VA-to-RA mapping. I've seen papers on some PPC Linuxes that handle large discontiguous real DRAM memory spaces, but it doesn't look like the Linux in ELDK does. Is that correct? This is just the start of a headache between the architects and we poor implementers. It's not clear to us that, even with ATMU support, how normal drivers are going to know how to create real addresses for buffers and such to use when programming DMA controllers or external PCI devices. Any comments would be VERY appreciated. Regards, J -- View this message in context: http://www.nabble.com/PPC-Discontiguous-Memory-Space-tf2279504.html#a6331980 Sent from the Uboot - Users forum at Nabble.com.

3 2

[U-Boot-Users] Does Uboot support BOOTME protocol
by Shiju Mathew 16 Sep '06

16 Sep '06

Hello, Does Uboot support bootme protocol ? Basically I want to boot wince image via platform builder (a tool to build wince image and support bootme protocol to download images to the target board). Thanks, Shiju

2 1

[U-Boot-Users] Newbie questions
by Bruce_Leonard＠selinc.com 15 Sep '06

15 Sep '06

Hi all, I'm totally new to embedded linux/uboot, but I've been doing embedded work for going on 12 years so I'm not a total putz. We're working on early stages of design and I've been asked a couple of questions that I can't really answer. I don't need to know HOW to do these just yet (can figure that out later), I just need to know if it's possible to do. And before you ask I am RTFMing, I just don't have a lot of time to come up with answers to these questions and they're not jumping out of the FM at me. So: 1) Will u-boot support a compact flash device on the local bus of an MPC8347 (we would like to get u-boot from a small I2C EEPROM and everything else including the kernel from a large compact flash device)? 2) Is it possible to connect to u-boot's "console" from an enet port or can it only be accessed from a serial port? If it can, I presume it can then be used to load new versions of u-boot just like the serial port? (The reason for this is there may not be a serial port available in the final design for the customer to use for field upgrades and we're concerned about being able to upgrade u-boot if we need to ship a fix for it in the future.) Thanks in advance. Bruce Leonard Schweitzer Engineering Labs ---------------------------------- This e-mail may contain SEL confidential or legally privileged information. The opinions expressed are not necessarily those of SEL. Any unauthorized disclosure, distribution or other use is prohibited. If you received this e-mail in error, please notify the sender, permanently delete it, and destroy any printed copies.

5 10

Re: [U-Boot-Users] [DNX#2006091542000018] PHzenARMA
by U-Boot patch tracking system 15 Sep '06

15 Sep '06

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2006091542000018]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

[U-Boot-Users] booting problem
by Srinivas rao 15 Sep '06

15 Sep '06

Hi All, I faced some problem while booting the linux Using tftp I copied the linux image into ram at 0x8000 after I used bootm command at that time its working fine. But whenever I copied the linux image into flash at 3 to 10 sectors and after I used bootm command but I getting error message like below ## Booting image at 1c060000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 997788 Bytes = 974.4 kB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux............................................................. ........ crc error -- System halted In cmd_bootm command I given 3rd sector addres(0X1c060000)of flash also. My flashdisk file system starting at 11th sector. Pls give me tha idea to solve the above problem. Thanks & Regards Srinivas Rao.Ch __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/

2 1

Re: [U-Boot-Users] Codesourcery Coldfire Compiler.
by Sandro M 14 Sep '06

14 Sep '06

Hello guys, hello Wolfgang I'm new of this mailing list :-) I'm interested about the Codesourcery Coldfire Compiler, but in this topic I wanted to download the attachment of this mail, but sourceforge tells me that the link doesnt exists! This link: http://sourceforge.net/mailarchive/forum.php?forum=u-boot-users/attachments… Where can i find that patch? Thanks in advance, Sandro > ------------------------------ > > Message: 6 > Date: Wed, 13 Sep 2006 02:37:30 +0200 > From: Wolfgang Denk <wd(a)denx.de> > Subject: Re: [U-Boot-Users] Codesourcery Coldfire Compiler. > To: John.Jeffers(a)bjservices.com > Cc: u-boot-users(a)lists.sourceforge.net > Message-ID: <20060913003730.00D98352658(a)atlas.denx.de> > Content-Type: text/plain; charset="iso-8859-1" > > In message > <OF073576BF.95160C24-ON862571E7.007944BE-862571E7.007AE32C(a)BJSERVICES.COM> > you wrote: >> Wolfgang hinted that he used codesourcery gcc for Coldfire. I know now > ... >> I would thank the group for telling me for U-Boot 1.1.4 from git should >> the uClinux or ELF GCC package be used from Codesourcery? (-m5307) 5235 >> processor naturally for Linux. > > To be precise: we used the GCC 4.1.0 based tools from CodeSourcery for > ColdFire > for Linux (kernel and applications), and the GCC 3.4.6 based buildroot > tools for U-Boot: > > - download buildroot from http://buildroot.uclibc.org/downloads/snapshots/ > (did this around mid May, so things might have changed since) > - apply attached patch > - copy attached config to .config > - run make menuconfig, go to "Build Options" and modify "Toolchain > and header file location" - this has to be final installation path; > toolchain will not work from other location > - create install directory selected above > - run make, when it's done toolchain should be ready to use in it's > final location > > Hope this helps. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > The world is no nursery. - Sigmund Freud > >

3 3

[U-Boot-Users] Debugging U-boot with BDI-2000 on MPC8349
by Ben Warren 14 Sep '06

14 Sep '06

Hello, Has anybody been able to successfully single step through U-boot code on an MPC8349 CPU using a BDI-2000? I've been working with an FAE at the company that represents Abatron in the US, and he seems to think it's a GDB problem. Of course, I'd prefer it to be something else... I'm using the ppc_6xx-gdb version 6.3 that's part of ELDK 4.0. I've also built the latest gdb 6.5, but no dice there either. Here's a snippet: (gdb) target remote 10.69.69.200:2001 Remote debugging using 10.69.69.200:2001 0x00000100 in ?? () (gdb) b board_init_f Breakpoint 1 at 0xfe0044a4: file board.c, line 374. (gdb) c Continuing. Breakpoint 1, board_init_f (bootflag=1) at board.c:374 374 { (gdb) list 369 * 370 ************************************************************************ 371 */ 372 373 void board_init_f (ulong bootflag) 374 { 375 bd_t *bd; 376 ulong len, addr, addr_sp; 377 ulong *s; 378 gd_t *id; (gdb) next Cannot access memory at address 0xfd000efc /****** This isn't an address in Flash! The BDI-2000 shows the PC incrementing, so 'next' did advance things ******/ (gdb) del 1 (gdb) b relocate_code Breakpoint 2 at 0xfe0035a0: file /bld_home/bwarren/fpga/u-boot/cpu/mpc83xx/start.S, line 888. (gdb) c Continuing. Breakpoint 2, relocate_code () at /bld_home/bwarren/fpga/u-boot/cpu/mpc83xx/start.S:889 889 mr r9, r4 /* Save copy of Global Data pointer */ (gdb) next 890 mr r10, r5 /* Save copy of Destination Address */ /****** We can single step through this code for some reason ******/ If anybody's seen this behavior and has any clues, please let me know. I apologize if this is a bit off-topic. regards, Ben

3 4