November 2005 - U-Boot

[U-Boot-Users] PCI_REGION_MEMORY and prefetchable PCI windows?
by Kumar Gala 22 Nov '05

22 Nov '05

I was wondering if the PCI_REGION_MEMORY had any real meaning. I see a number of places in which its set, but none that actual use it for anyting. The only thing I see it doing is ensuring that system memory has a unique 'flags' value from PCI memory. Is this the intent? Also, I'm starting to look at adding the ability to register a PCI memory region as prefetchable and handle allocations of devices that have BARs that are prefetchable. I plan on modeling this after the code that handles pci_mem, any comments? thanks - kumar

1 0

[U-Boot-Users] help
by prabha.j＠tcs.com 22 Nov '05

22 Nov '05

Hi all, In the README file of U-boot i saw that the CFG_SDRAM_BASE (physical address ) should be 0x0. But why ? For my board the SDRAM starts from 0x3000 0000.(128MB). Then how can i change. If i change how it will be effected. Give me some idea on this. Thanks in advance. Prabha J. Tata Consultancy Services Limited Mailto: prabha.j(a)tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

2 1

[U-Boot-Users] if i dont want to use env in the test stage, how to set the config file?
by zhuzhenhua 22 Nov '05

22 Nov '05

i only had i flash(2M) at 0xbfc00000 i set as #define PHYS_FLASH_1 0xbfc00000 /* Flash Bank #1 */ #define CFG_FLASH_BASE PHYS_FLASH_1 #define CFG_NO_FLASH 1 /* Flash is not usable now */ #define CFG_ENV_IS_NOWHERE 1 /* Store ENV in memory only */ #define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000 is there any other define need to set? regards zhuzhenhua

2 1

[U-Boot-Users] [PATCH][BUGFIX] Incorrect handling of AT91RM9200 timer overflow
by Anders Larsen 22 Nov '05

22 Nov '05

Hi, the AT91RM9200 timer functions are confusing apples with bananas. When the (16-bit) timer overflows, we have lost exactly 2^16 counts (or a multiple thereof, but we currently can't catch that situation), but get_timer_raw() instead adds the (unrelated) conversion factor to milliseconds, causing udelay() to potentially return too early. The patch below fixes this. Cheers Anders CHANGELOG: Fix incorrect handling of at91rm9200 timer overflow in get_timer_raw() Patch by Anders Larsen, 11 Nov 2005 Signed-off-by: Anders Larsen <alarsen(a)rea.de> --- cpu/arm920t/at91rm9200/interrupts.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/arm920t/at91rm9200/interrupts.c b/cpu/arm920t/at91rm9200/interrupts.c index 1054602..68ad58b 100644 --- a/cpu/arm920t/at91rm9200/interrupts.c +++ b/cpu/arm920t/at91rm9200/interrupts.c @@ -108,7 +108,7 @@ ulong get_timer_raw (void) timestamp += now - lastinc; } else { /* we have an overflow ... */ - timestamp += now + TIMER_LOAD_VAL - lastinc; + timestamp += now + 0x10000 - lastinc; } lastinc = now;

2 1

[U-Boot-Users] why there is __asm__ __volatile__("": : :"memory") in board_init_f(lib_mips/board.c), but not in board_init_r?
by zhuzhenhua 22 Nov '05

22 Nov '05

i see theres lines in board_init_f(lib_mips/board.c) /* compiler optimization barrier needed for GCC >= 3.4 */ __asm__ __volatile__("": : :"memory"); but there is not the same lines in board_init_r? why it do not need in the board_init_r? regards

1 0

RE: [U-Boot-Users] Bug in StrataFlash drivers
by Menon, Nishanth 21 Nov '05

21 Nov '05

Greetings, I can see it hit here too: case FLASH_CFI_32BIT: cnt = len >> 2; break; default: it is a div 4operation.. so last 3 bytes may go missin!! Mebbe I am wrong abt it.. but then.. so it seems.. Regards, Nishanth Menon > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of llandre > Sent: Friday, November 11, 2005 4:27 AM > To: Wolfgang Denk > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Bug in StrataFlash drivers > > >>>Do you have a spoecific test case that shows the presence of the bug? > >> > >>I experience the problem when trying to store in Flash my ramdisk image > >>that is 1502693 bytes. > > > > > > This will probably also happen with smaller size? > Yes, I think it will happen with any odd-sized files. > > > >>>And can you please provide a proper patch, with CHANGELOG entry, > >>>Signed-off-by line and everything? > See attached file. > > ChangeLog: > * Patch by Andrea Marson, 11 November 2005: > Fixed odd-sized images writing in Zefeer StrataFlash driver. > > > Signed-off-by: Andrea Marson <r&d2(a)dave-tech.it> > > > > > Best regards, > llandre > > DAVE Electronics System House - R&D Department > web: http://www.dave-tech.it > email: r&d2(a)dave-tech.it

3 2

[U-Boot-Users] u-boot debug suggestions
by Don Pruitt 21 Nov '05

21 Nov '05

Hi, I have a custom board running a 405GPr that is based off of the walnut ref board with the exception that we have a 512KB boot prom starting @ fff80000 which is where I burn uboot. I have ported u- boot-1.1.3 to the board with the assistance of a BDI2000 which seems to work well. I get the uboot UI and am able to read and write to sdram and flash, however if I remove the jtag uboot crashes at startup. My first thought was that it's a timing issue as the jtag would hold the board in reset on power up. I questioned this when I discovered that I can somewhat simulate this with the BDI2000 by issuing a reset run 1000. This approach would seem to indicate that it is crashing when attempting to access an sdram address. What I don't understand is why there would be a difference with the sdram initialization between powering up the target and issuing a bdi >go and issuing a >reset run xxxx? Any suggestions you have would be greatly appreciated! thanks, Don Pruitt

3 2

[U-Boot-Users] u-boot hang in board_init_r(for mips)
by zhuzhenhua 21 Nov '05

21 Nov '05

hi, every one i wan tto port a u-boot on a 4kec fpga board( cpu speed just 12M now) i used the sdram with no cache on. i add some printf in board_init_f and board_init_r the printf in board_init_f will output every time,the printf in board_init_r sometimes output,sometimes not if i use bdi2000 to debug, it printf correct in board_init_r and hang at function devices_init(). i have read the manuel at eldk's page, which said that reason for hang after relocate_code maybe caused by sdram access by cache.but i do not use the cache does there any other reason maybe cause that? thanks ! regards zhuzhenhua

1 0

[U-Boot-Users] Changing all '$(...)' variable references into '${...}'
by Wolfgang Denk 20 Nov '05

20 Nov '05

Hello everybody, please note that I have checked in a patch to change all '$(...)' variable references into '${...}'. In case you did not know: this syntax has been supported for > 18 months. The big advantage is that such an environment definition is compatible with the hush shell, i. e. when you decide to switch the command line parser there is no trouble with your environment definitions. Note that the old syntax [i. e. '$(...)'] will be discontinued in later versions of U-Boot. Please use '${...}' instead. 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 Men don't talk peace unless they're ready to back it up with war. -- Col. Green, "The Savage Curtain", stardate 5906.4

1 0

[U-Boot-Users] Format of MMUCSR0 on 8540
by Charles J Gillan 18 Nov '05

18 Nov '05

I downloaded U-boot from CVS on Nov 14th and have compiled and run this on a TQM8540 board (with a Rev 2 MPC8540 chip). However, I started stepping through this with the CodeWarrior debugger (and a FreeScale USB TAP - COP version) find that the "isync" in the following code from start.S is actually causing Interrupt 14 to be executed (TLBInstructionException). /* * Invalidate MMU L1/L2 * * Note: There is a fixup earlier for Errata CPU4 on * Rev 1 parts that must precede this MMU invalidation. */ li r2, 0x001e mtspr MMUCSR0, r2 isync <------------------- Interrupt Without CodeWarrior, I do eventually see the U-Boot command line appear on the serial port (however it did take several seconds after power on, more than I expected). Checking the 8540RM manual, I see that there appear to be only two bits that need to be set to invalidate cache (page 633 on MMUCSR0). Can anyone on the explain the presence of 0x001e as opposed to 0x0006 in the above code? Any suggestions as to why this exception arises. Has anyone seen it with An Abatron BDI2000 or not - as the case may be. Thanks, Charles. -------------------------------------------------------------------------- Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847 Fax: +44 (0) 2890 971702 --------------------------------------------------------------------------

3 5