February 2007 - U-Boot

[U-Boot-Users] fixup section problem.
by Txema Lopez 12 Feb '07

12 Feb '07

Hi, We are working in a MPC5200B based custom board and we are developping a tool to relocate a U-Boot (1.1.4 version) binary file to a different address in flash that it was linked. So, we have to change the GOT and FIXUP entries in the original file to point at the new address. Doing this work, we have found that, surprisingly, the FIXUP section in U-Boot is empty. When U-Boot is relocated from flash to sdram these lines in the file start.S have no effect: /* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ 2: li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 addi r3,r3,-4 beq 4f 3: lwzu r4,4(r3) lwzux r0,r4,r11 add r0,r0,r11 stw r10,0(r3) stw r0,0(r4) bdnz 3b 4: Looking into the sources we have found some places where the fixup elements seem to be relocated manually, i.e.: void malloc_bin_reloc (void) { DECLARE_GLOBAL_DATA_PTR; unsigned long *p = (unsigned long *)(&av_[2]); int i; for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) { *p++ += gd->reloc_off; } } Is there any reason to leave the FIXUP section empty in U-Boot? Is it a bug?. Checking the u-boot.lds file for the IceCube board we have found that fhe fixup section is included in the TEXT section and in the RELOC section, but the linker generate code only for the TEXT section. If we put it only in the RELOC section the FIXUP is not empty, the pointers adjustement in the start.S seems to work properly and the malloc_bin_reloc() function would be not necessary. Does anynone know if I'am missing something? Any clue will be welcomed. Best regards,

3 5

Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
by Michel Benoit 11 Feb '07

11 Feb '07

Hello. As a current user of Atmel's AT91SAM9260, I encourage the effort to get at91sam926x inserted into the main u-boot branch. I'm willing help test u-boot on the at91sam9260ek board. Michel On 2/10/07, u-boot-users-request(a)lists.sourceforge.net <u-boot-users-request(a)lists.sourceforge.net> wrote: > Send U-Boot-Users mailing list submissions to > u-boot-users(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/u-boot-users > or, via email, send a message with subject or body 'help' to > u-boot-users-request(a)lists.sourceforge.net > > You can reach the person managing the list at > u-boot-users-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of U-Boot-Users digest..." > > > Today's Topics: > > 1. Re: BDI2000 config for MPC8360rev2 with DDR2 memory? > (Medve Emilian-EMMEDVE1) > 2. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen) > 3. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson) > 4. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen) > 5. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson) > 6. 1 digital camera manufacturer. (Goldberg Rachel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Feb 2007 15:22:55 -0700 > From: "Medve Emilian-EMMEDVE1" <Emilian.Medve(a)freescale.com> > Subject: Re: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 > memory? > To: <u-boot-users(a)lists.sourceforge.net> > Message-ID: > <598D5675D34BE349929AF5EDE9B03E27C181C6(a)az33exm24.fsl.freescale.net> > Content-Type: text/plain; charset="us-ascii" > > Hi Steve, > > > You could get the configuration files from Abatron > (ftp://83.125.32.26/bdigdb/config/powerpc/mpc83xx/). That should be > enough to just flash the board. > > > Cheers, > Emil. > > > This e-mail, and any associated attachments have been classified as: > ==================================================================== > [x] Public > [ ] Freescale Semiconductor Internal Use Only > [ ] Freescale Semiconductor Confidential Proprietary > > > -----Original Message----- > From: u-boot-users-bounces(a)lists.sourceforge.net > [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Steven > Hein > Sent: Friday, February 09, 2007 4:06 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory? > > Hi all-- > > I just received a new custom board with an MPC8360r2 with 128MB DDR2 > memory on the board. My 8360EMDS board has a rev 1.2 part with DDR, > so I know I need a different set of init registers in my BDI2000 config. > If anyone has a similar config and could send me a BDI2000 config file > for it, that would be AWESOME! In the mean time, I'm trying to > flash u-boot directly into my flash part using the BDI2000 and let it > initialize my memory for me. But this is all fairly uncharted > territory for me, so a BDI config would be helpful. > > Thanks! > Steve > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Steve Hein (ssh(a)sgi.com) Engineering Diagnostics/Software > Silicon Graphics, Inc. > 1168 Industrial Blvd. Phone: (715) 726-8410 > Chippewa Falls, WI 54729 Fax: (715) 726-6715 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > ------------------------------------------------------------------------ > - > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your job > easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > > ------------------------------ > > Message: 2 > Date: Fri, 9 Feb 2007 23:58:16 +0100 > From: "Haavard Skinnemoen" <hskinnemoen(a)gmail.com> > Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK > To: "Ulf Samuelsson" <ulf(a)atmel.com> > Cc: u-boot-users(a)lists.sourceforge.net, Wolfgang Denk <wd(a)denx.de>, > Haavard Skinnemoen <hskinnemoen(a)atmel.com> > Message-ID: > <1defaf580702091458p564ba747qc235ebe3601df497(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/07, Ulf Samuelsson <ulf(a)atmel.com> wrote: > > > The only thimg I'm not really happy with (whithout having any better > > > suggestion) is to move this into drivers - drivers is intended for > > > general, CPU and board independent code, where this is obviously > > > specific to a certain class of processors. > > It's somewhat cpu- and board-independent. at32 and at91 are based on > two different architectures, so they don't have any directories in > common apart from the ones common to everyone. > > We could perhaps create a drivers/atmel subdirectory or, as Ulf > suggests, boards/atmel/drivers or cpu/atmel/drivers. > > > I think at45.c is CPU independent, but spi.c is closely tied to Atmel > > processors. > > spi.c consist of: > > > > SpiInit - Clearly CPU dependent due to pin mux. > > Only reason that sam926x chips can use a common file > > is the #ifdefs... > > Hmm...how about moving the cpu-dependent bits into inline functions > somewhere under asm/arch? For example > > static inline void portmux_enable_spi(unsigned int id) > { > /* do chip-dependent PIO stuff here */ > } > > asm/arch is chip-specific so there shouldn't be any need for #ifdefs there. > > > While the functions in at45.c are called AT91xxx they really do not > > depend on any specific SPI H/W and it can thus be used > > with any chip which implements the SPI API defined > > by cpu/arm920t/at91rm9200/spi.c > > Yeah, that's why the AT91 prefixing should be dropped. But that's for > much later. > > Btw, looks like there's another SPI API in u-boot as well. Probably a > good idea to convert the at91/atmel spi stuff over to implementing > that one. No point in having several APIs doing the same thing, and > the other API uses the much more sensible function name spi_xfer for > doing SPI transfers, as opposed to AT91F_SpiWrite which is totally > misleading since it's being used for reading as well. > > > If you let it remain in the board directories as is, then > > you duplicate this for each board. > > I don't think anyone wants that. Although you're the one suggesting we > add a _third_ identical driver ;-) > > > I think a good place for any driver stuff which is useable > > both by at91 and ap7xxx chips could be an > > board/atmel/drivers directory. > > An alternative would be a cpu/atmel/drivers directory. > > Are any other drivers organized this way? > > > I do not think it belongs inside the drivers directory. > > I'm sorry but I fail to see why not. There are several other > platform-specific drivers in there. And I don't really see the big > advantage of spreading drivers around all over the place... > > > By putting spi.c in drivers you have to be really careful not to compile > > this for chips which does not have this SPI macro. > > Yeah, but if it's protected by an easy-to-understand #ifdef that > shouldn't be a problem. Although I don't think we should call it spi.c > then. It should be atmel_spi.c or something. > > > The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init. > > Or do it in a chip-specific header file. > > > I still would like to have the complete sam926x patch set > > implemented before we start to "play" with it > > Yeah, but I still think some preparatory patches are a good thing in > order to make things easier later on. > > Haavard > > > > ------------------------------ > > Message: 3 > Date: Sat, 10 Feb 2007 00:20:21 +0100 > From: "Ulf Samuelsson" <ulf(a)atmel.com> > Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK > To: "Haavard Skinnemoen" <hskinnemoen(a)gmail.com> > Cc: u-boot-users(a)lists.sourceforge.net, Wolfgang Denk <wd(a)denx.de>, > Haavard Skinnemoen <hskinnemoen(a)atmel.com> > Message-ID: <012b01c74ca1$8ee35fe0$01c4af0a@Glamdring> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > > > >> I still would like to have the complete sam926x patch set > >> implemented before we start to "play" with it > > > > Yeah, but I still think some preparatory patches are a good thing in > > order to make things easier later on. > > I only see two things as a result of those prepatory patches. > > 1) Bugs > 2) Delays in availability > > I am not questioning anything you want to do, just the timing. > If we follow your recommendation you will have a bunch > of untested board patches in the mainstream u-boot, > for the sam926x. > > I do not have the time to thoroughly test any changes > you do (I dont even have an at91sam9263 board). > > If we go my way, then we should be able to have *tested* sam926x > support inside U-boot very soon, and while this results > in duplication of a small part of the spi code on the source level > (no addition to the binary) I believe that > the benefit to the community of at91sam926x users > of having native support in U-Boot outweighs this duplication a lot. > > The number of users far outweisghs the number of implementers > and I think that we need to look at it from their point of view. > > We are not introducing any new interfaces here, > just using the existing interfaces. > This means that it will not be harder to do any modifications > *after* the sam926x patches are applied. > It will be easier since you have better overview. > > The only alternative I can see is that you take over > the responsibility for both AVR32 and AT91 U-boot > and test all modifications on all boards before submission > - Still with availability of working solution as the highest priority. > > > > > > Haavard > > > Best Regards > Ulf Samuelsson > > > > ------------------------------ > > Message: 4 > Date: Sat, 10 Feb 2007 00:42:27 +0100 > From: "Haavard Skinnemoen" <hskinnemoen(a)gmail.com> > Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK > To: "Ulf Samuelsson" <ulf(a)atmel.com> > Cc: u-boot-users(a)lists.sourceforge.net, Wolfgang Denk <wd(a)denx.de>, > Haavard Skinnemoen <hskinnemoen(a)atmel.com> > Message-ID: > <1defaf580702091542m19034fddu9e1d3eb4fccf0d64(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/10/07, Ulf Samuelsson <ulf(a)atmel.com> wrote: > > The number of users far outweisghs the number of implementers > > and I think that we need to look at it from their point of view. > > Would help a lot to have some of those users help with testing though. > > > We are not introducing any new interfaces here, > > just using the existing interfaces. > > This means that it will not be harder to do any modifications > > *after* the sam926x patches are applied. > > It will be easier since you have better overview. > > Whatever. Please let me know when you're ready to continue. > > > The only alternative I can see is that you take over > > the responsibility for both AVR32 and AT91 U-boot > > and test all modifications on all boards before submission > > - Still with availability of working solution as the highest priority. > > I don't think that's going to happen. Besides, having the same person > implement and test the code usually doesn't work very well anyway, so > if we're going to do this we need people willing to test > probably-working-but-still-experimental stuff. > > I'm of course not saying that I can't be bothered to test my > modifications before submitting, but relying on me to implement _and_ > test everything on all configurations is just insane. > > Haavard > > > > ------------------------------ > > Message: 5 > Date: Sat, 10 Feb 2007 01:10:55 +0100 > From: "Ulf Samuelsson" <ulf(a)atmel.com> > Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK > To: "Haavard Skinnemoen" <hskinnemoen(a)gmail.com> > Cc: u-boot-users(a)lists.sourceforge.net, Wolfgang Denk <wd(a)denx.de>, > Haavard Skinnemoen <hskinnemoen(a)atmel.com> > Message-ID: <014701c74ca8$920caf30$01c4af0a@Glamdring> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > > On 2/10/07, Ulf Samuelsson <ulf(a)atmel.com> wrote: > >> The number of users far outweisghs the number of implementers > >> and I think that we need to look at it from their point of view. > > > > Would help a lot to have some of those users help with testing though. > > > >> We are not introducing any new interfaces here, > >> just using the existing interfaces. > >> This means that it will not be harder to do any modifications > >> *after* the sam926x patches are applied. > >> It will be easier since you have better overview. > > > > Whatever. Please let me know when you're ready to continue. > > > > I am ready to continue as soon as at45_split is applied. > It is a real simple patch, it divides one more or less duplicated file into > two files. > > If I try to apply any sam926x patches without that, > then It will crash the at91rm9200dk and cmc_pu2 board support. > > Once this patch is applied, I can submit the at91sam926x patches > and if/when they are accepted, then we have accomplished the most > important goal to Atmel customers, > which is that *tested* sam926x support is available from the primary > U-Boot location and that you can build both at91 and avr32 > from the same source code. > > I consider all other activities secondary. > > Best Regards > Ulf Samuelsson ulf(a)atmel.com > Atmel Nordic AB > Mail: Box 2033, 174 02 Sundbyberg, Sweden > Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden > Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 > GSM +46 (706) 22 44 57 > > Technical support when I am not available: > AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com > AT90 AVR Applications Group: mailto:avr@atmel.com > AT91 ARM Applications Group: mailto:at91support@atmel.com > FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR > > > > > ------------------------------ > > Message: 6 > Date: Sat, 10 Feb 2007 02:27:15 +0200 > From: Goldberg Rachel <krihl(a)canpub.fr> > Subject: [U-Boot-Users] 1 digital camera manufacturer. > To: u-boot-users(a)lists.sourceforge.net > Message-ID: <45CD1163.1090109(a)canpub.fr> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... >

2 1

[U-Boot-Users] Well, the old one was good and lasted long enough but I felt it had its limitations and outlived its days.
by Isaiah Farmer 11 Feb '07

11 Feb '07

3incremental policy installer for PIXHere is the changeLogNightly builds are done on the following systems:FreeBSD 4. This is useful if thename of the obejct is not unique. Bug that caused firewall script to break during transfer to the firewall if any of the rule or object comments used non-english UTF-8 characters has been fixed. You can create a newfirewall object using one for these templates. The "Help me build firewall policy" wizard was phased outand replaced with firewall templates. It won't work with the original firmware. GUI has a built-in installer that uses external ssh clientto communicate with firewall. 11This is a bugfix release. 2 using QT packages that come with these systems.

1 0

[U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
by wei.zhang＠freescale.com 11 Feb '07

11 Feb '07

From: Zhang Wei <wei.zhang(a)freescale.com> For the flash of port width more than 8bit, a completetly read must be performed. For example, 16bit port width flash must perform a ushort read. Otherwise, some flashes will get error data. Signed-off-by: Zhang Wei <wei.zhang(a)freescale.com> --- drivers/cfi_flash.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c index 9b10220..f02b047 100644 --- a/drivers/cfi_flash.c +++ b/drivers/cfi_flash.c @@ -250,9 +250,9 @@ #endif */ inline uchar flash_read_uchar (flash_info_t * info, uint offset) { - uchar *cp; + uchar cp[FLASH_CFI_64BIT]; - cp = flash_make_addr (info, 0, offset); + memcpy(cp, flash_make_addr (info, 0, offset), info->portwidth); #if defined(__LITTLE_ENDIAN) return (cp[0]); #else -- 1.4.0

12 54

[U-Boot-Users] Next Big market Winner!
by obvious 10 Feb '07

10 Feb '07

1 0

Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
by Ulf Samuelsson 10 Feb '07

10 Feb '07

> Hej, > > Has anyone used the at91_nand driver on the AT91SAM9260EK? > > I get bad erase blocks on every block that contaions data (written to > nand flash with SAM-BA). Seems like the read_oob (read out of bounds > area) function is returning data from the in bounds area. > > U-boot configs the nand flash to use hw ecc (syndrome) whereas the > at91_nand seems to be setup to use soft ecc. > According to recent conversations on U-Boot mailing list U-boot can do a raw copy of a flash file system, but nothing more. (Correct me if I have misunderstood) This means that if there are faulty pages in the NAND flash, you are dead. U-Boot needs to be able to map out JFFS2 or YAFFS(2) to be useful here. I.E. NAND flash is not functional as a boot memory yet. If I understand correctly, you can read a JFFS2 fs in U-Boot With the SAM9260, you can boot from an external dataflash card, containing Linux and a small file system. When this has booted, I think you can create a JFFS2 file system on the NAND flash. This should contain the Linux image as well. U-Boot should then after reset, be able to read the linux from the JFFS2 file system and then boot. I do not know if U-boot can fit into the NAND flash and I have not tested anything of above, but I think it should work. The programming time of the system will of course be significant, since you have to test the NAND flash for bad sectors.. > If anyone has been down this path before, I would appreciate any > pointers or assistance you can provide. > > Michel > > ------------------------------------------------------------------- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php > Best Regards Ulf Samuelsson

7 21

[U-Boot-Users] 1 digital camera manufacturer.
by Goldberg Rachel 10 Feb '07

10 Feb '07

1 0

[U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory?
by Steven Hein 09 Feb '07

09 Feb '07

Hi all-- I just received a new custom board with an MPC8360r2 with 128MB DDR2 memory on the board. My 8360EMDS board has a rev 1.2 part with DDR, so I know I need a different set of init registers in my BDI2000 config. If anyone has a similar config and could send me a BDI2000 config file for it, that would be AWESOME! In the mean time, I'm trying to flash u-boot directly into my flash part using the BDI2000 and let it initialize my memory for me. But this is all fairly uncharted territory for me, so a BDI config would be helpful. Thanks! Steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Hein (ssh(a)sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

[U-Boot-Users] MPC8360 Rev 2 patch?
by Steven Hein 09 Feb '07

09 Feb '07

Hello-- I read the recent post regarding the MPC8360 rev 2 patch that is currently in development for u-boot 1.2.0. How soon will that patch be available (or the code submitted to the tree)? I have a custom board arriving at the end of the week that will have an 8360 rev2....and it has DDR2 memory so I'll need DDR2 support. Is there somewhere that I can download the latest bits to get started? Thanks, Steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Hein (ssh(a)sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 10

[U-Boot-Users] Next Big market Winner!
by drive. 09 Feb '07

09 Feb '07

1 0