June 2004 - U-Boot

Re: [U-Boot-Users] mpc8260 reset procedure
by walter dicarlo 14 Jun '04

14 Jun '04

Hi Wolfgang, thanks for your advice. I haven't yet investigate issues related to booting Linux, but my idea was to move IMMR at 0x04700000 or 0x14700000 at the end of u-boot debugging/configuration. Walter --- Wolfgang Denk <wd(a)denx.de> wrote: > In message > <20040614093531.37881.qmail(a)web60005.mail.yahoo.com> > you wrote: > > > > I don't remeber the details but I have been forced > to > > define the CFG_DEFAULT_IMMR. However, now, I have > > understood that the default IMMR should point to > the > > begin of the register area (in my case 0x0f010000) > > while CFG_IMMR should point to the begin of the > > processor memory map (in my case 0x0f000000). > > Just to mention that this will bring you in trouble > as soon as you > attempt to boot Linux, since a 0x0F...... address > does not meet the > Linux kernel memory mapping requirements. > > > > 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 > When some people discover the truth, they just can't > understand why > everybody isn't eager to hear it. > __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

2 1

Re: [U-Boot-Users] mpc8260 reset procedure
by walter dicarlo 14 Jun '04

14 Jun '04

Hi Gerald, it seems my problem was caused by the fact that CFG_DEFAULT_IMMR was not pointing to the correct register area (in my case 0x0f010000 but not 0x10000). I thing it is a little bit confusing the names CFG_DEFAULT_IMMR and CFG_IMMR. The first point to the initial register area while the second point to the final memory map. In any case, I will follow your advice to not change the value of IMMR in the code while still debugging. Thanks a lot Walter __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

[U-Boot-Users] mpc8260 reset procedure
by walter dicarlo 14 Jun '04

14 Jun '04

Hi all, I am new to embedded world and I am trying to port u-boot on a board based on the mpc8260. I hope I can bore you a little bit with a simple question. I use the Lauterbach Trace32 to program the 4Mb flash. I compile u-boot 1.0.2 using the following settings: �TEXT_BASE = fff00000 �CFG_DEFAULT_IMMR = 00010000 �CFG_IMMR = 0f000000 �CFG_SDRAM_BASE = 00000000 �CFG_FLASH_BASE = ffc00000 �CFG_BR0_PRELIM = ffc01001 �CFG_OR0_PRELIM = ffc00856 �CFG_BR1_PRELIM = 00000041 �CFG_OR1_PRELIM = f8002b00 �HRCW = 08 c2 01 07 Note that I use three Trace32 scripts to: - init the board - store the HRCW at the begin of the flash (FFC00000) - store the u-boot.bin at fff00000 � My problem is with the HRCW and the reset procedure. It is not clear how it works and what steps I should follow to setup everything. � When I start debugging, the Program Counter starts correctly from fff00100, but as soon as the code starts to manage IMMR everything seems to not work. It is like the code expect the registers in one position but in reality it is in another location. � I know it is basic knoledge about the mpc8260 but do you have any advices? Thanks � Walter __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

3 3

[U-Boot-Users] LCD on pxa255
by himba 14 Jun '04

14 Jun '04

Hi, I'm trying to hook up passive LCD to pxa255, so I defined my LCD type and CONFIG_LCD in config and created vidinfo_t struct in cpu/pxa/pxafb.c. I compiled and burned it to flash. After reboot I get: U-Boot 1.0.2 (Jun 8 2004 - 23:06:10) U-Boot code: A3F00000 -> A3F18530 BSS: -> A3F1BFB4 RAM Configuration: Bank #0: a0000000 64 MB Bank #1: a4000000 0 kB Bank #2: a8000000 0 kB Bank #3: ac000000 0 kB Flash: 32 MB [LCD] Initializing LCD frambuffer at 00000000 palette_mem_size = 0x00000200 Configuring PXA LCD vid: vl_col=320 hslen=3 lm=2 rm=3 vid: vl_row=240 vslen=1 um=0 bm=0 fbi->dmadesc_fblow = 0x149d0 fbi->dmadesc_fbhigh = 0x149e0 fbi->dmadesc_palette = 0x149f0 fbi->dmadesc_fblow->fdadr = 0x6d657263 fbi->dmadesc_fbhigh->fdadr = 0x6d6d fbi->dmadesc_palette->fdadr = 0x64646120 fbi->dmadesc_fblow->fsadr = 0x69746e65 fbi->dmadesc_fbhigh->fsadr = 0x2c622e5b fbi->dmadesc_palette->fsadr = 0x73736572 fbi->dmadesc_fblow->ldcmd = 0x0 fbi->dmadesc_fbhigh->ldcmd = 0x5d6c2e20 fbi->dmadesc_palette->ldcmd = 0x6d202d20 Setting GPIO for 8 bit data Enabling LCD controller FDADR0 = 0x64646120 FDADR1 = 0x000149d0 LCCR0 = 0x00301078 LCCR1 = 0x0102093f LCCR2 = 0x000000ef LCCR3 = 0x0340ff20 setcolreg: reg 0 @ 00014a00: R=00 G=00 B=00 => 6D65 setcolreg: reg 1 @ 00014a02: R=FF G=00 B=00 => 726F setcolreg: reg 2 @ 00014a04: R=00 G=FF B=00 => 2079 setcolreg: reg 3 @ 00014a06: R=FF G=FF B=00 => 6F6D setcolreg: reg 4 @ 00014a08: R=00 G=00 B=FF => 6964 setcolreg: reg 5 @ 00014a0a: R=FF G=00 B=FF => 7966 setcolreg: reg 6 @ 00014a0c: R=00 G=FF B=FF => 202C setcolreg: reg 14 @ 00014a1c: R=AA G=AA B=AA => 6461 setcolreg: reg 15 @ 00014a1e: R=FF G=FF B=FF => 7264 [LCD] Test Pattern: 320 x 240 [107 x 120] [LCD] Drawing the logo... -- hang ?! -- No logo appears and no test pattern is visible (LCD is powered on and blanked/or with some horizontal lines drawn). Has anybody successfuly connected passive LCD to pxa ? regards ,himba

2 1

RE: [U-Boot-Users] Can U-Boot be divided into TWO stages
by Woodruff, Richard 13 Jun '04

13 Jun '04

Using which processor? Someone I work with has NAND only boot working. If you are using an OMAP we might be able to help. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of chaidy(a)lenovo.com > Sent: Saturday, June 12, 2004 10:39 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] Can U-Boot be divided into TWO stages > > > Hi, everyone. > > I'm a newbie on U-Boot. > As I would not use any NOR Flash on > my project, U-Boot and > Linux Kernel are both seated on the > NAND Flash. The bootrom > can boot only a piece of code not > more than 16K, so I must > cut U-Boot down to 16k or divide it > into two stages (like GRUB). > > I am at the very beginning point > and > look forward to ANY hints > from U. Thanks a lot. > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] Can U-Boot be divided into TWO stages
by chaidy＠lenovo.com 13 Jun '04

13 Jun '04

Hi, everyone. I'm a newbie on U-Boot. As I would not use any NOR Flash on my project, U-Boot and Linux Kernel are both seated on the NAND Flash. The bootrom can boot only a piece of code not more than 16K, so I must cut U-Boot down to 16k or divide it into two stages (like GRUB). I am at the very beginning point and look forward to ANY hints from U. Thanks a lot.

2 1

RE: [U-Boot-Users] RPX Classic Question
by Matt Hoover 12 Jun '04

12 Jun '04

Travis, The image for PlanetCore should be on the CD for the RPX module. If not we can forward it to you. I have attached the script for the Abitron BDI and RPX Classic (CLLF). Regarding uboot, we only support PlanetCore, but uboot has been ported to several of the RPX modules so you should be able to find it. Please advise if you have any questions. Regards, Matt Hoover -----Original Message----- From: Travis Sawyer [mailto:tsawyer+u-boot@sandburst.com] Sent: Thursday, June 10, 2004 1:14 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] RPX Classic Question Greetings u-boot'ers: Slightly off topic: I have in my possession several Embedded Planet RPX Classic boards. (Currently orphaned according to the readme). They have the EP boot firmware loaded in the flash. I've tried running they're 'program flash' code in an attempt to get u-boot into the flash to no avail. The flash is soldered down and I have no bdi firmware for the 860. (this is a personal project, so no budget for debugger FW). Does anyone have instructions for burning u-boot into the flash using their program? It looks like I have to wrap the u-boot.bin with something, but it isn't intuitive from their documentation. TIA, travis ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] problem with saveenv command if CFG_ENV_IS_IN_EEPROM...
by sean chang 12 Jun '04

12 Jun '04

Hi all, A quick question. If I have my environment variables stored in eeprom (i.e. define CFG_ENV_IS_IN_EEPROM), I should be able to use the saveenv command to save any user modified env values back to eeprom right? But U_BOOT_CMD saveenv does not get compiled unless I have defined both CFG_CMD_ENV and CFG_CMD_FLASH. Also, if you look at the function do_saveenv, which is called when user uses the saveenv command, it does get compiled if I only define CFG_ENV_IS_IN_EEPROM alone. Am I missing something or is there a problem? Any help is greatly appreciated. Thanks, Sean copied from common/cmd_nvedit.c ================================================================================ #if ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == (CFG_CMD_ENV|CFG_CMD_FLASH)) U_BOOT_CMD( saveenv, 1, 0, do_saveenv, "saveenv - save environment variables to persistent storage\n", NULL ); #endif /* CFG_CMD_ENV */ #if (CONFIG_COMMANDS & CFG_CMD_ASKENV) =================================================================== #if defined(CFG_ENV_IS_IN_NVRAM) || defined(CFG_ENV_IS_IN_EEPROM) || \ ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == \ (CFG_CMD_ENV|CFG_CMD_FLASH)) int do_saveenv (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { extern char * env_name_spec; printf ("Saving Environment to %s...\n", env_name_spec); return (saveenv() ? 1 : 0); }

2 1

Re: [U-Boot-Users] How to reduce the size of u-boot image file
by Frank Young 12 Jun '04

12 Jun '04

Hi Wolfgang, >in message <BAY2-F84Hoouifm0Sx700057af6(a)hotmail.com> you wrote: > > > > 1. Because of the size of the flash memory constraint, I need to strip >the > > u-boot to its minimum size. Right now by executing "make all" in the >u-boot > > directory, I got a image file u-boot at around 700K-800K. It's too big >for > >You must be joking. I haven't seen any configuration yet which exceeds 256 >kB. > >Did you by any chance look at the ELF file which includes all the >hewaders, symbol tables, debug informnation etc.? > >Forget about this one. How big is your u-boot.bin file? > No kidding at all. I am extremely serious about this. If I don't change anything, then I got a u-boot as big as 716,334 bytes. The u-boot.bin is about 500K if I don't change the TEXT_BASE in board/walnut/config.mk. If I change the CONFIG_COMMANDS to default value, it is reduced to 576,931. But how would you get it less than 256KB? The command I used to build u-boot is very simple: make distclean make WALNUT405_config make all But before that I have to change a line in examples/Makefile $(OBJCOPY) -O binary $< $@ 2>/dev/null to: $(OBJCOPY) -O binary $<:.srec=) $@ 2>/dev/null I don't think this change will affact the size of the image. Am I right? > > my target. So I am thinking about getting rid of some functionalities >which > > u-boot provides. I do need u-boot to initialize my hardware. But after >that, > > I only need to use tftp to get the linux image, decompress the image, >put > > the decompressed image in RAM and jump to the linux entry point to let >the > > linux take over the control. Is there any FAQ or manual explaining how >to > > strip down the u-boot size? > >Yes. The README explains how to enable or disable commands or command >groups. > Got it. Thanks! > > 2. Since my flash memory address starts from 0xFFC00020 instead of > >Please check again. I think it is IMPOSSIBLE to have a flash start >address of 0xFFC00020. I guess you mean 0xFFC00000 ? Yes, you are right, the flash begins from 0xFFC00000. But I need to reserve the first 0x20 for my special purpose, so the available flash is from 0xFFC00020. Can u-boot be aligned from this address? Thanks! Frank _________________________________________________________________ Watch the online reality show Mixed Messages with a friend and enter to win a trip to NY http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/

2 1

RE: [U-Boot-Users] lib_arm/board.c calls eth_init() for smc91111...why?
by Woodruff, Richard 11 Jun '04

11 Jun '04

I don't think it needs to be there. Doing a 'mac' init is all that I would think need be done. It doesn't have the big delay of the phy init but gets rid of u-boot to kernel handshake issues, and also sets up the environment. In board's I used in the past, I just did the mac init section in misc_init_r and not a full ethinit. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of Paul Ruhland > Sent: Thursday, June 10, 2004 2:59 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] lib_arm/board.c calls eth_init() for > smc91111...why? > > I noticed when my board booted with the latest CVS there was an unusually > long > delay (3-4 seconds) before the prompt came up. I initially thought it had > hung. Turns out a call to 'eth_init()' was recently added in > 'lib_arm/board.c'. Since 'eth_init()' is called from 'Net_Loop()' why do > we > need the call in board.c? It adds quite a large delay to the bootup time > that I think is unnecessary. > > -- > Paul Ruhland <pruhland(a)microwavedata.com> > Software Engineer > Microwave Data Systems > Rochester, NY 16420 > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1