February 2007 - U-Boot

[U-Boot-Users] [DNX#2007022742000015] [PATCH] add output of 'size' to bui [...]
by DENX Support System 27 Feb '07

27 Feb '07

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2007022742000015] was created: <snip> > In message <c166aa9f0702261446g2f449c7bmfe0f76492ac76b94(a)mail.gmail.com> > you wrote: > > > > patch adds a call to the appropriate version of 'size' and prints > > output like so during make: > > > > cd /home/adyer/Projects/u-boot && arm-linux-size u-boot > > text data bss dec hex filename > > 128878 7843 20532 157253 26645 u-boot > > NAK. > > This patch violates the rule that "make -s" must not produce any > output for succcesful builds. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk > Office: Kirchenstr. 5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > It is necessary to have purpose. > -- Alice #1, "I, Mudd", stardate 4513.3 </snip> Your U-Boot support team

1 0

[U-Boot-Users] [DNX#2007022742000015] [PATCH] add output of 'size' to build
by U-Boot patch tracking system 27 Feb '07

27 Feb '07

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#2007022742000015]. 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] Submitting patches
by Matt Gessner 27 Feb '07

27 Feb '07

Hi, The README file doesn't cover how to submit patches for U-Boot using git. Is it as simple as just pulling the diffs out for each file and submitting them? Should I post separate patch files as attachments in the same email? I also didn't find anything on the www.denx.de site relating to this. Any preference? Thanks, Matt Gessner

3 7

[U-Boot-Users] [DNX#2007022642000035] [PATCH] add output of 'size' to build
by DENX Support System 26 Feb '07

26 Feb '07

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2007022642000035] was created: <snip> > patch adds a call to the appropriate version of 'size' and prints > output like so during make: > > cd /home/adyer/Projects/u-boot && arm-linux-size u-boot > text data bss dec hex filename > 128878 7843 20532 157253 26645 u-boot > > just before making the srec and bin versions. I find it handy to keep > track of how big things are getting. > > Signed-off-by: Andrew Dyer <amdyer(a)gmail.com> > > -- > Hardware, n.: > The parts of a computer system that can be kicked. </snip> Your U-Boot support team

1 0

[U-Boot-Users] [DNX#2007022642000035] [PATCH] add output of 'size' to build
by U-Boot patch tracking system 26 Feb '07

26 Feb '07

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#2007022642000035]. 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] mpc8641d and CONFIG_VERY_BIG_RAM
by Chris Fester 26 Feb '07

26 Feb '07

Hi all, We're in the process of bringing up our custom board which has an mpc8641d part on it. I've been basing most of my u-boot code off of the jdl git tree's MPC8641HPCN platform. In the file include/configs/MPC8641HPCN.h, CONFIG_VERY_BIG_RAM is set. But I'd like to know why, or more specifically, what was the original intent of this parameter. Currently with my configuration it has the effect of relocating u-boot just below 256MB, even though I have a gig of memory on the board. If I undefine CONFIG_VERY_BIG_RAM, the effect is more of what we desire. In particular, u-boot gets relocated to the very top of memory. This makes dram tests much easier to run, since we can run them with one big range of memory, rather than having to split into two ranges. After some greps of the code I see comments like this: #define CONFIG_VERY_BIG_RAM /* we will use up to 256M memory for cause we are short of BATS*/ /* Define CONFIG_VERY_BIG_RAM to allow use of SDRAMs larger than 256MBytes But what's interesting is the only place it seems to be used is in lib_ppc/board.c: #ifndef CONFIG_VERY_BIG_RAM addr = CFG_SDRAM_BASE + gd->ram_size; #else /* only allow stack below 256M */ addr = CFG_SDRAM_BASE + (gd->ram_size > 256 << 20) ? 256 << 20 : gd->ram_size; #endif Is the comment about the stack below 256M a historical one for older cpus? Or will I be facing problems later if my stack is higher than that? Thanks for any hints and/or insight! :) Chris

2 1

[U-Boot-Users] rtc/ds1374.c turns clock OFF when it means to turn it ON
by Andrew Klossner 26 Feb '07

26 Feb '07

rtc/ds1374.c mistakes the "don't enable the oscillator" bit for a "do enable the oscillator bit" and sets it to 1, stopping the clock. My guess is that nobody has actually used rtc_set or rtc_reset with this driver. We've been using this chip for a few years with a proprietary OS and are now switching to u-boot and Linux. I revised the u-boot driver based on our stable driver. Besides fixing the oscillator bit, I set it up to read all the registers with a single IIC transaction for efficiency and to see any error code from the IIC subsystem. I would attach the new driver here but I can't figure out how. I'm typing through a broken "hello new user, we don't yet trust you" web page. If somebody could send instructions to andrew(a)cesa.opbu.xerox.com, I'd like to submit this revision. Andrew Klossner

3 2

[U-Boot-Users] Solved SPI controller 880 hangs in u-boot 1.2.0 (writing to help someone)
by DI BACCO ANTONIO - technolabs 26 Feb '07

26 Feb '07

I don't use the CFG_SPI_UCODE_PATCH but it seems that in u-boot-1.2.0 the setting spi->spi_rpbase = 0; done in order to disable relocation causes my 8xx controller to hang. I removed that line and it works fine. Because I consider myself the newbie(st) on the mailing list, I would like a comment from a competent people. Here is the code snippet in ./cpu/mpc8xx/spi.c #ifdef CFG_SPI_UCODE_PATCH spi = (spi_t *)&cp->cp_dpmem[spi->spi_rpbase]; #else spi = (spi_t *)&cp->cp_dparam[PROFF_SPI]; /* Disable relocation */ // spi->spi_rpbase = 0; #endif

2 1

Re: [U-Boot-Users] Added a SATA support for INTEL processors with ICH-5 in u-boot.
by Markus Klotzbücher 26 Feb '07

26 Feb '07

Dear Mushtaq, mushtaq khan <mushtaq_k(a)procsys.com> writes: > With the latest u-boot code checked-out, got the following compilation > errors, when configured for board sc520_cdp. I am afraid I can't help with this. > I could resolve the above errors with some changes in code. For these > changes i have made patch and attached with the mail. Please send patches (especially such small ones) and their description inline as plain text. A lot more people will actually look at it. And please no *.doc files. Best regards Markus -- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany

3 2

[U-Boot-Users] SecretaryGeneral Lars Seeberg has resigned as Secretary General after mutual agreement!
by Duran 26 Feb '07

26 Feb '07

1 0