January 2008 - U-Boot

[U-Boot-Users] Booting Standalone App?
by onyxtape 31 Jan '08

31 Jan '08

Hi there, So what are the steps to get u-boot to boot the hello_world example? I'm evaluating the PowerPC 440-based AMCC Yosemite board. This is what I have done: gzip hello_world.bin mkimage -A ppc -0 linux -T standalone -C gzip -a 40000 -e 40004 -n "Standalone" -d hello_world.bin.gz hello_world.ub Then I loaded the ub file onto the board at 0x40000. Then when I tried to bootm 40000, it would uncompress the standalone app (Uncompressing Standalone Application ... OK) then stop after showing 2 symbols. What am I doing wrong? I'm a complete newbie to u-boot and I've tried to find discussions online and reading the DULG, but I'm not having too much luck... Thanks! -- View this message in context: http://www.nabble.com/Booting-Standalone-App--tp15172456p15172456.html Sent from the Uboot - Users mailing list archive at Nabble.com.

3 4

[U-Boot-Users] [rfc] new spiflash subsystem
by Mike Frysinger 31 Jan '08

31 Jan '08

this isnt against u-boot mainline, so there will be a few things that are out of date (like the CFG handling), so over look that part. what's up for comments here is the general architecture. ive omitted the env_spiflash.c portion as i think that'll be pretty cheesy. basically ive laid it out like so: - common/cmd_spiflash.c: provides the user interface of the spiflash subsystem. depends on these functions being implemented elsewhere: * spiflash_info() - ask the spiflash driver for info * spiflash_read() - ask the spiflash driver to read * spiflash_write() - ask the spiflash driver to write * spiflash_erase() - ask the spiflash driver to erase no validation occurs in the common code since it has no idea about sector sizes and such. i could add a spiflash_query() function and have it return a struct describing the spiflash and use that to validate, but i dont think it's really worth the effort. relevant defines: * CFG_CMD_SPIFLASH - include the "spiflash" command * CFG_SPIFLASH_MULTI - support multiple parts (via "cs" parameter) - drivers/mtd/spiflash_jedec.c: provides the spiflash driver functions needed by the common layer. detects and works with Spansion/ST/Atmel/Winbond parts. i've personally verified at least one part from each family, but obviously not every part ;). it depends on these functions being implemented elsewhere: * spiflash_on() - turn on the SPI * spiflash_off() - turn off the SPI * spiflash_cs_set() - assert/deassert the specified chip select * spiflash_exchange_byte() - send specified byte and return received byte relevant defines: * CFG_SPIFLASH_JEDEC_DRIVER - enable this driver * CFG_SPIFLASH_MULTI - disable a small runtime opt to avoid redetection - board/$BOARD/spiflash.c: provides the board / cpu specific spiflash functions. ive included the Blackfin one here as an example. -mike

8 26

[U-Boot-Users] [PATCH] ColdFire: Fix 5282 and 5271 interrupt mask bit
by Tsi-Chung Liew 30 Jan '08

30 Jan '08

From: TsiChungLiew <Tsi-Chung.Liew(a)freescale.com> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> --- cpu/mcf52x2/interrupts.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/mcf52x2/interrupts.c b/cpu/mcf52x2/interrupts.c index 2ccbde5..9167cec 100644 --- a/cpu/mcf52x2/interrupts.c +++ b/cpu/mcf52x2/interrupts.c @@ -77,7 +77,7 @@ void dtimer_intr_setup(void) volatile int0_t *intp = (int0_t *) (CFG_INTR_BASE); intp->icr0[CFG_TMRINTR_NO] = CFG_TMRINTR_PRI; - intp->imrl0 &= ~0xFFFFFFFE; + intp->imrl0 &= 0xFFFFFFFE; intp->imrl0 &= ~CFG_TMRINTR_MASK; } #endif /* CONFIG_MCFTMR */ -- 1.5.2

1 0

[U-Boot-Users] MPC8xx I2C
by Ben Warren 30 Jan '08

30 Jan '08

Hi, I'm trying to rationalize some very common I2C code and came across the following: Every controller except cpu/mpc8xx implements functions like this: --- uchar i2c_reg_read(uchar i2c_addr, uchar reg) { uchar buf; i2c_read(i2c_addr, reg, 1, &buf, 1); return buf; } void i2c_reg_write(uchar i2c_addr, uchar reg, uchar val) { i2c_write(i2c_addr, reg, 1, &val, 1); } --- cpu/mpc8xx, however, adds i2c_init() calls: --- uchar i2c_reg_read(uchar i2c_addr, uchar reg) { uchar buf; i2c_init(CFG_I2C_SPEED, CFG_I2C_SLAVE); i2c_read(i2c_addr, reg, 1, &buf, 1); return (buf); } void i2c_reg_write(uchar i2c_addr, uchar reg, uchar val) { i2c_init(CFG_I2C_SPEED, CFG_I2C_SLAVE); i2c_write(i2c_addr, reg, 1, &val, 1); } --- Can somebody lend historical perspective as to why these i2c_init() calls are needed? thanks, Ben

1 0

[U-Boot-Users] errors in using DS1337
by xiangguo_li＠hotmail.com 30 Jan '08

30 Jan '08

hello, when I choose to use DS1337, I add definitions in header file: #define CONFIG_RTC_DS1337 #define CFG_I2C_RTC_ADDR 0x68 but, during making process, error appears: rtc/librtc.a(ds1337.o): in function 'rtc_read': .../rtc/ds1337.c: 172: undefined reference to 'i2c_reg_read' rtc/librtc.a(ds1337.o): in function 'rtc_write': .../rtc/ds1337.c: 178: undefined reference tp 'i2c_reg_write' how to solve this error? thank you. -lxg

2 5

[U-Boot-Users] [ARM] Available patch: s3c24xx: Multiple serial port support
by Peter Pearse 30 Jan '08

30 Jan '08

Harald Your patch ARM: s3c24xx: Multiple serial port support is available for test from git://linux-arm.org/u-boot-armdev.git#071219_s3c24_serial Please confirm that the code builds, and runs on the target board(s) Regards Peter

1 0

[U-Boot-Users] [ARM] Available patch: ARM: arm920t: Allow use of 'gd' pointer from IRQ
by Peter Pearse 30 Jan '08

30 Jan '08

Harald Your patch ARM: arm920t: Allow use of 'gd' pointer from IRQ is available for test from git://linux-arm.org/u-boot-armdev.git#071219_s3c24_gd Please confirm that the code builds, and runs on the target board(s) Just in case you weren't aware, the gd pointer will not be available in FIQ interrupts unless you add some code to initialize it (and ensure fiq r8 is preserved in any FIQ handlers) I shall submit a patch in future to change the ARM gd pointer to r7. This will allow a) The gd pointer to to be accessed in both IRQ & FIQ handlers, without added initialization code b) Thumb & Thumb-2 compilation without code change in this area c) Support for future ARM architectures. Regards Peter

1 0

Re: [U-Boot-Users] [PATCH ARM 0/5] AT91CAP9 support
by Peter Pearse 30 Jan '08

30 Jan '08

> -----Original Message----- > From: Stelian Pop [mailto:stelian@popies.net] > Sent: 29 January 2008 19:57 > To: Peter Pearse > Subject: Re: [U-Boot-Users] [PATCH ARM 0/5] AT91CAP9 support > > Hi Peter, > > > This series of patches adds support for Atmel's AT91CAP9 > Customizable > > Microcontrollers family: > [...] > Added to my list..... Regards Peter

1 0

[U-Boot-Users] NAND driver question
by Craig Millen 30 Jan '08

30 Jan '08

I have been experiencing a few problems when using a NAND flash for storage in u-boot. When I'm reading large files (7MB) from the NAND, periodically there will be a NAND ECC read error when using the following command: => nand read 400000 0 154000 NAND read: device 0 offset 0x0, size 0x154000 1392640 bytes read: ERROR. After turning on debug, the problem is occurring in the nand_read_ecc function whereby the ecc check fails. After running it numerous times, there seems to be no correlation between pages that fail and appears to be completely random. Has anyone else had these problems? Furthermore, the "nand write" command doesn't skip bad blocks. Are you supposed to use a different command to write files to the NAND that skips the bad blocks? Thanks Craig

3 2

[U-Boot-Users] Reg to Know about U boot Porting
by Karthikeyan Kadirvel, Chennai 30 Jan '08

30 Jan '08

Hai friends I am new to this U loader I have to porting U loader for a MCF54450 processor. So can u direct me? What are the things have to concentrate on. Thanks. Karthikeyan K, HCL Technologies Ltd, Tel: +91-44-42169999 Extn. (2683), www.hcl.in. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. -----------------------------------------------------------------------------------------------------------------------

2 1