September 2006 - U-Boot

[U-Boot-Users] Linux Hangs After Uncompressing Kernel
by wenwen 07 Oct '06

07 Oct '06

i download a 6M Byte kernel(28M bytes uncompressed) to SDRAM(0x4000000), it hangs after uncompressing kernel. when i use standalone downlod the kernel, i found the text section which offset is 8M bytes is not the same as the objdump file of the elf file. is there any limited size about kernel ? i used amcc ppc440 sequoia board

3 3

[U-Boot-Users] What the right procedure should be when write a new driver for U-boot?
by Lyoo 05 Oct '06

05 Oct '06

Hi maintainer There is some confusion about what the right procedure should be, when someone want to add some drivers to U-boot. When I read U-boot's code, I found the devices initialize function devices_init() (called in /u-boot-x.x.x/lib_xxx/board.c), It creates a device list, then dev_xxx_init() register the devices such as LCD, USB, Serial, Keyboard in the list. But, some SOC have their own drivers, for example s3c24x0 have their own driver of USB, Serial,(/cpu/arm920t/s3c24x0/usb_ohci.c) they don't care about the device list, they do it their way. Is there any 'official' policy on it?

2 1

[U-Boot-Users] U-boot AMCC yosemite board 440EP
by Föll, Tobias 05 Oct '06

05 Oct '06

Hi, i have a hardware which is very near to the yosemite board called JC-670. The yosemite board has 4 DDR chips and my hardware has only two chips (2*Micron 64V16M16 has 256Mbit...), because i need only 256MBit*2Chips=512MBit=64Mbyte. It seem that i have problems with the DDR interface. I downloaded the u-boot bin file from the AMCC -> denx page, and programmed it into the flash on my hardware called JC-670. On the serial output i saw that the system starts up. But then it hangs... Here is the first output hardware JC-670: =========================================== U-Boot 1.1.4-ga2c95a72 (Jul 28 2006 - 19:32:28) CPU: AMCC PowerPC 440EP Rev. B at 666.666 MHz (PLB=266, OPB=133, EBC=133 MHz) I2C boot EEPROM enabled Internal PCI arbiter disabled, PCI async ext clock used 32 kB I-Cache 32 kB D-Cache Board: Yosemite - AMCC PPC440EP Evaluation Board I2C: ready DRAM: Software has not detected the DRAM ! Here is the second output hardware JC-670: ========================================== U-Boot 1.1.4-ga2c95a72 (Jul 28 2006 - 19:32:28) CPU: AMCC PowerPC 440EP Rev. B at 666.666 MHz (PLB=266, OPB=133, EBC=133 MHz) I2C boot EEPROM enabled Internal PCI arbiter disabled, PCI async ext clock used 32 kB I-Cache 32 kB D-Cache Board: Yosemite - AMCC PPC440EP Evaluation Board I2C: ready DRAM: 256 MB U-boot software has detected the DRAM's. I can try this several times the difference is that sometimes i got the DRAM size(like first output) and somtimes not (like second output). Thats all. Must i change the u-boot code if i only use two DDR Chips ? On the moment i can not generate a new u-boot bin , because it will not work with cygwin under windows.I tried it. And i'am not a linux expert, because of this i can not do this work under linux on the moment. Has anybody an idea why sometimes the "256 MB" text will not come ? For me it looks like the sdram_init() function in yosemite.c sometimes hangs. Regards Tobias

4 4

[U-Boot-Users] linux kernel porting bug
by Piyush Khandelwal 04 Oct '06

04 Oct '06

Hi all, We are porting linux kernel for an ARM11 board. During the bootup process, it hangs in Calibrate_delay() specifically it hangs on the while(ticks == jiffies); wait loop. We are not able to find what interrupt changes jiffies. Can we know what could be the problem. Thanks in advance, Piyush --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

3 3

[U-Boot-Users] MPC5840 local bus speed
by Gerrit Van de Velde 02 Oct '06

02 Oct '06

Hi all, I'm not sure if it's entirely on topic but here we go: We've been trying to set the local bus speed of the MPC8540 to 82MHz without much success until now. We're using Uboot 1.1.4 with our own board.c code mostly ripped from the 8540ADS board. In the code there's some info about a workaround for the DLL of te cpu: /* * Errata LBC11. * Fix Local Bus clock glitch when DLL is enabled. * * If localbus freq is < 66Mhz, DLL bypass mode must be used. * If localbus freq is > 133Mhz, DLL can be safely enabled. * Between 66 and 133, the DLL is enabled with an override workaround. */ But actually, the 82Mhz is in between those values. In this code, the U-Boot stops working after the LCRR is assigned and doesn't even get to the udelay part (checked with printfs) lbc->lcrr = CFG_LBC_LCRR & (~0x80000000); /* DLL Enabled */ Udelay(200); Disabling or enabling has the same result, the clock speed of the bus has changed though to 82MHz (checked it with the scope). Has anyone of you some pointers on what to check or what to try out? Regards, Gerrit

2 1

Re: [U-Boot-Users] (no subject)
by Gerald Jackson 30 Sep '06

30 Sep '06

Here is the error I get if I use the second DIMMS U-Boot 1.1.4 (Jul 18 2006 - 07:36:20) CPU: AMCC PowerPC 440GX Rev. F at 800 MHz (PLB=160, OPB=80, EBC=40 MHz) I2C boot EEPROM enabled Internal PCI arbiter enabled 32 kB I-Cache 32 kB D-Cache Board: Ocotea - AMCC PPC440GX Evaluation Board I2C: ready DRAM: ERROR: Cannot determine a common read delay. ### ERROR ### Please RESET the board ### Gerald -----Original Message----- From: Gerald Jackson Sent: Friday, September 29, 2006 6:16 PM To: Marc.Howard(a)KLA-Tencor.com; sr(a)denx.de; u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] (no subject) Marc, After you make that change you can use both dimms slot on the ocotea board? What error did you receive before the modification? if I use only the second dimm slot with 256M it errors. if I use the first dimm slot it is ok and if I use both dimms slot it error as well. I am using 1.1.4. Gerald -----Original Message----- From: "Howard, Marc"<Marc.Howard(a)KLA-Tencor.com> Sent: 9/28/06 5:06:26 PM To: "Stefan Roese"<sr(a)denx.de>, "u-boot-users(a)lists.sourceforge.net"<u-boot-users(a)lists.sourceforge.net> Subject: Re: [U-Boot-Users] (no subject) Stefan, Actually > 256MB won't work correctly. There is a problem in board/amcc/ocotea/init.S: tlbtab: tlbtab_start tlbentry( 0xf0000000, SZ_256M, 0xf0000000, 1, AC_R|AC_W|AC_X|SA_G|SA_I) tlbentry( CFG_PERIPHERAL_BASE, SZ_256M, 0x40000000, 1, AC_R|AC_W|SA_G|SA_I) tlbentry( CFG_ISRAM_BASE, SZ_4K, 0x80000000, 0, AC_R|AC_W|AC_X ) tlbentry( CFG_ISRAM_BASE + 0x1000, SZ_4K, 0x80001000, 0, AC_R|AC_W|AC_X ) tlbentry( CFG_SDRAM_BASE, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_G|SA_I ) tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_G|SA_I ) tlbentry( CFG_PCI_BASE, SZ_256M, 0x00000000, 2, AC_R|AC_W|SA_G|SA_I ) tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I ) tlbtab_en The line: tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_G|SA_I ) ...should be... tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x10000000, 0, AC_R|AC_W|AC_X|SA_G|SA_I ) ^ ------------------------------------------------^ The way it currently stands virtual addresses 256-512MB are mapped into the same region as the 1st 256MB of SDRAM. Marc Howard > -----Original Message----- > From: u-boot-users-bounces(a)lists.sourceforge.net > [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf > Of Stefan Roese > Sent: Thursday, September 28, 2006 5:48 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] (no subject) > > Hi Gerald, > > On Thursday 28 September 2006 04:03, Gerald Jackson wrote: > > Does anyone know why u-boot 1.1.4 fails if you use two dimms in the > > Ocotea Amcc board? > > > > I have try two 256 dimm, two 512 dimm, and one 256 dimm in > the second > > slot ( nothing in the first slot) it all fails. > > > > Is this a know problem with the Ocotea board? > > No. IIRC, we have tested Ocotea with different DIMM modules. > Which U-Boot > version are you using? What DIMM modules are you using? And > what combination > _is_ working? > > A quick look at the TLB setup shows me, that a maximum of > 512MBytes could be > working. For more at least the TLB setup has to be changed. > > Best regards, > Stefan > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys -- and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

Re: [U-Boot-Users] [DNX#2006093042000016] [PATCH] NAND Flash verify across block boundaries
by DENX Support System 30 Sep '06

30 Sep '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006093042000016] was created: <snip> > Hello, > > This patch addresses a problem when CONFIG_MTD_NAND_VERIFY_WRITE is > defined > and the write crosses a block boundary. The pointer to the verification > buffer (bufstart) is not being updated to reflect the starting of the > new > block so the verification of the second block fails. > > Regards, > Nick > > > CHANGELOG: > > * Fix NAND FLASH page verification across block boundaries > > > > diff --git a/drivers/nand/nand_base.c b/drivers/nand/nand_base.c > index b7a5d32..6b13c4e 100644 > --- a/drivers/nand/nand_base.c > +++ b/drivers/nand/nand_base.c > @@ -1713,6 +1713,7 @@ static int nand_write_ecc (struct mtd_in > goto out; > } > *retlen = written; > + bufstart = (u_char*) &buf[written]; > > ofs = autoplace ? mtd->oobavail : mtd->oobsize; > if (eccbuf) </snip> Your U-Boot support team

1 0

Re: [U-Boot-Users] [DNX#2006093042000016] [PATCH] NAND Flash verify across block boundaries
by U-Boot patch tracking system 30 Sep '06

30 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#2006093042000016]. 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] [PATCH] NAND Flash verify across block boundaries
by Spence Nick-rxtd10 30 Sep '06

30 Sep '06

Hello, This patch addresses a problem when CONFIG_MTD_NAND_VERIFY_WRITE is defined and the write crosses a block boundary. The pointer to the verification buffer (bufstart) is not being updated to reflect the starting of the new block so the verification of the second block fails. Regards, Nick CHANGELOG: * Fix NAND FLASH page verification across block boundaries diff --git a/drivers/nand/nand_base.c b/drivers/nand/nand_base.c index b7a5d32..6b13c4e 100644 --- a/drivers/nand/nand_base.c +++ b/drivers/nand/nand_base.c @@ -1713,6 +1713,7 @@ static int nand_write_ecc (struct mtd_in goto out; } *retlen = written; + bufstart = (u_char*) &buf[written]; ofs = autoplace ? mtd->oobavail : mtd->oobsize; if (eccbuf)

1 0

[U-Boot-Users] DCR register read/write for PPC440EP
by Leonid 30 Sep '06

30 Sep '06

Hi, I'm trying to read certain configuration register (SDR0_PINSTP) using u-boot setdcr/getdcr commands (I run 1.1.4 u-boot on AMCC PPC440EP Yosemite board). First thing I do is setting this register's offset (0x40) in the SDR0_CFGADDR (0xE) DCRN: => setdcr e 000e: 00000020 ? 40 000e: 00000040 ? => However it doesn't look having any effect: => getdcr e 000e: 00000020 And when I read SDR0_CFGDATA (0xF), I get register with offset 0x20 (SDR0_SDSTP0) as expected: => getdcr f 000f: 8570828a Before I start to debug do_setdcr() function, may be somebody knows this issue and it was even fixed? Thanks, Leonid.

2 5