July 2004 - U-Boot

[U-Boot-Users] bootm change for standalone images
by Andrew May 29 Jul '04

29 Jul '04

I need to boot a HW test program and it expects to be loaded down at address 0x0 with the interrupt vectors laid out. So it is like a stupid homegrown OS. I came up with this quick fix to check for a load to address 0x0 for a standalone type, and not re-enable interrupts. But I am not sure if the check would be universal. Would it better to add a new type or flag to image header. It looks like RTEMS is the simplest OS loader and it should work as is with my image, but it would be nice to have a generic print instead.

2 8

[U-Boot-Users] PPC 8260 Linux boot
by Ori Idan 29 Jul '04

29 Jul '04

I am trying to boot Linux 2.4.25 (code from denx linux-2-4-devel) The board is similar to MPC8260ADS What happens is that the kernel is starting but after a short while gets an exception and the board is reset again. We tried looking at the kernel sources to see where we get, we did this by lighting hardware LEDS we have on the board. We tried to find where in the kernel we get the exception, we could not find exactly where it happens, but we did find that it happens somewhere in the function prom_init called from early_init inside arch/ppc/kernel/setup.c Does anyone have any idea what we should look next? -- Ori Idan

2 8

[U-Boot-Users] DHCP/BOOTP with CONFIG_NET_MULTI
by Figini Enzo 29 Jul '04

29 Jul '04

Hi. Simple question : I'm using u-boot 1.1.0 and I need to boot Linux using DHCP; in my board there is more than one eth line available. Until now I have been using TFTP with CONFIG_NET_MULTI defined and all was good, but looking the dhcp code for this step I see that dhcp doesn't support more than one eth line (get mac address only from the first). Is there any reason for this or is a bug ? regards, Enzo

2 3

[U-Boot-Users] ELDK Linux Compile problem
by Victor Wren 28 Jul '04

28 Jul '04

Sorry if this is the wrong list for this. I hunted around for an ELDK specific list, but came up empty. I got u-boot to compile with ELDK for the Lite5200 board, and I'm moving on to getting Linux to work. When I was using version2 of the ELDK and u-boot 1.0.1, I got it up and running and reading the hard disk, so I'd like to get up at least to where I was before (I moved to the newer version because of the USB and RTC support). I'm trying to compile a kernel for the Lite5200 board. I can successfully compile it with an incomplete IDE configuration, like this: CONFIG_IDE=y CONFIG_BLOCK_DEV_IDE_MODES=y But when I add the hardware driver: CONFIG_BLOCK_DEV_IDE_MPC5xxx=y the compile crashes. I'm using ELDK 3.0 (not the CVS), which has the modified 2.4.24 kernel. Here's the error message, which appears to be happening in the linker: ppc_82xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head.o arch/ppc/kernel/idle_6xx.o init/main.o init/version.o init/do_mounts.o \ --start-group \ arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/ide/idedriver.o drivers/pci/driver.o drivers/mtd/mtdlink.o drivers/macintosh/macintosh.o drivers/media/media.o arch/ppc/5xxx_io/5xxx_io.o \ net/network.o \ /usr/local/ELDK/ppc_82xx/usr/src/linux-2.4.24/lib/lib.a \ --end-group \ -o vmlinux arch/ppc/platforms/platform.o(.text.init+0xf2): In function `platform_init': : undefined reference to `mpc5xxx_ide_get_base' arch/ppc/platforms/platform.o(.text.init+0xfa): In function `platform_init': : undefined reference to `mpc5xxx_ide_get_base' arch/ppc/platforms/platform.o(.text.init+0x10e): In function `platform_init': : undefined reference to `mpc5xxx_ide_init_hwif_ports' arch/ppc/platforms/platform.o(.text.init+0x116): In function `platform_init': : undefined reference to `mpc5xxx_ide_init_hwif_ports' drivers/ide/idedriver.o(.text.init+0xacc): In function `probe_for_hwifs': : undefined reference to `mpc5xxx_ide_probe' drivers/ide/idedriver.o(.text.init+0xacc): In function `probe_for_hwifs': : relocation truncated to fit: R_PPC_REL24 mpc5xxx_ide_probe ppc_82xx-make: *** [vmlinux] Error 1 ------------------------------------- My apologies if this has already been fixed in CVS. If it has, I'll get current and try again. Victor Wren Victor Wren Designer, Timension Inc. 1350 C Pear Ave Mountain View CA 94043 (650) 564-9397 Fax: (650) 564-9398 Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.

2 1

[U-Boot-Users] Flawed ATAG passing
by Christian Kapeller 28 Jul '04

28 Jul '04

Hi. While trying to get Linux (2.4.19-rmk7-pxa2 and 2.6.7-mm7) start with a ramdisk on a xm250 board, i discovered, that uboot 1.1.1 seems to have a problem passing the ATAGs to the kernel. Here is some debug output with linux 2.6.7-mm7 ==== u-Boot 1.1.1 (Jul 28 2004 - 17:11:18) U-Boot code: A3F80000 -> A3F998AC BSS: -> A3F9DBD8 RAM Configuration: Bank #0: a0000000 64 MB Bank #1: a4000000 0 kB Bank #2: a8000000 0 kB Bank #3: ac000000 0 kB Flash: 32 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 3 2 1 0 Using MAC Address 00:40:42:01:65:AA BOOTP broadcast 1 got BOOTP packet (src=67, dst=68, len=300 want_len=300) Filtering pkt = 0 Bootfile: uImage [BOOTP] Checking extension (300 bytes)... [BOOTP] Processing extension 1... (4 bytes) [BOOTP] Processing extension 3... (4 bytes) [BOOTP] Processing extension 6... (4 bytes) [BOOTP] Processing extension 15... (16 bytes) [BOOTP] Processing extension 28... (4 bytes) [BOOTP] Received fields: NetOurSubnetMask : 255.255.255.0 NetOurGatewayIP : 192.168.0.1 Got good BOOTP TFTP from server 192.168.0.1; our IP address is 192.168.0.3 Filename 'uImage'. Load address: 0xa3000000 Loading: *T ################################################################# ################################################################# ########################### done Bytes transferred = 799312 (c3250 hex) ## Booting image at a3000000 ... Image Name: Linux-Image Created: 2004-07-28 18:10:20 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 799248 Bytes = 780.5 kB Load Address: a0200000 Entry Point: a0200000 Verifying Checksum ... OK OK ## Loading Ramdisk Image at 00200000 ... Image Name: initrd Created: 2004-07-27 16:09:34 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 2517544 Bytes = 2.4 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Initrd at 00200040. Size 2517544## Transferring control to Linux (at address a0200000) ... ## setup_start_tag ## setup_memory_tags start a0000000 size:04000000 ## setup_commandling_tag size:0000001c line: root=/dev/ram0 init=/linuxrc ## setup_initrd_args start:00200040, end:00466a68 ## setup_end_tag Starting kernel ... Uncompressing Linux......................................................... done, booting the kernel. Linux version 2.6.7-mm7 (chrkap@allesodernix) (gcc version 3.3.3) #21 Wed Jul 28 18:10:04 UTC 2004 CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE) CPU: D undefined 5 cache CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Machine: Intel DBPXA250 Development Platform (aka Lubbock) parse_tags number of tags: 5 parsing tag: 0x54410001 parse_tag: tag 0x54410001 parse_tag_core parsing tag: 0x54410002 parse_tag: tag 0x54410002 parse_tag_mem32 start 0xa0000000 size 0x01000000 Memory policy: ECC disabled, Data cache writeback Memory clock: 99.53MHz (*27) Run Mode clock: 398.13MHz (*4) Turbo Mode clock: 398.13MHz (*1.0, inactive) On node 0 totalpages: 4096 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: root=/dev/ram console=ttyS0,115200 PID hash table entries: 128 (order 7: 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 16MB = 16MB total Memory: 14376KB available (1366K code, 346K data, 76K init) Calibrating delay loop... 397.31 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 NetWinder Floating Point Emulator V0.97 (double precision) ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Using anticipatory io scheduler physmap flash device: 4000000 at 0 cfi_cmdset_0001: Erase suspend on write enabled Using buffer write method cmdlinepart partition parsing not available RedBoot partition parsing not available pxa2xx_udc: version 14-Dec-2003 usb0: Ethernet Gadget, version: St Patrick's Day 2004 usb0: using pxa2xx_udc, OUT ep2out-bulk IN ep1in-bulk usb0: MAC 1a:60:19:07:1a:f0 mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 2048) NET: Registered protocol family 1 Kernel panic: VFS: Unable to mount root fs on unknown-block(1,0) ==== It seems that the kernel recieves all tags u-boot provided, but not all are parsed. Which seems strange, since none of the parse_tag_* functions in arch/arm/kernel/setup.c which are called by parse_tags(), can return something other than 0 which means that parse_tags() should read the next tag wich it doesn't. Has anybody experienced something simmilar, is this a known issue?

3 3

[U-Boot-Users] BCSR
by Knowledge Seeker 28 Jul '04

28 Jul '04

I see following line in board/fads/fads.h file #define BCSR_ADDR ((uint) 0xFF080000) Can anybody tell me where this definition comes from. Cannot find any reference. Abu Sana

4 5

RE: [U-Boot-Users] how to program u-boot to flash?
by Aric Wang 28 Jul '04

28 Jul '04

#define CONFIG_COMMANDS (CONFIG_CMD_DFL & ~CFG_CMD_NET) Yes, I saw this. It should mean that no network command is supported. I think that mean no network function is supported too. I change the line to : #define CONFIG_COMMANDS (CONFIG_CMD_DFL) and compile failed. Regards, -Aric In message <2A5969FA1F2BAE48BA505A2BD83BD965020E5B5C(a)shamsg10.corp.jabil.org> you wrote: > It's ok now. Nothing is changed from u-boot-1.1.1. I don't know why. I don't know either. > BTW, does u-boot 1.1.1 for ixdp425 already support ethernet? What do you see when checking the board config file? ... #define CONFIG_COMMANDS (CONFIG_CMD_DFL & ~CFG_CMD_NET) ... Guess what this means... Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de No more blah, blah, blah! -- Kirk, "Miri", stardate 2713.6

1 0

RE: [U-Boot-Users] how to program u-boot to flash?
by Aric Wang 28 Jul '04

28 Jul '04

It's ok now. Nothing is changed from u-boot-1.1.1. I don't know why. BTW, does u-boot 1.1.1 for ixdp425 already support ethernet? -Aric In message <2A5969FA1F2BAE48BA505A2BD83BD965020E5B52(a)shamsg10.corp.jabil.org> you wrote: > > I compiled u-boot 1.1.1 under cygwin for Coyote board with "make > ixdp425_config && make all". I use BDI2000 or Insight to load "u-boot" to > the board. It runs well after I commented out below lines in "cpu/ixp/start. > S": ... > If I don't comment out this, it will die on "mov r1, #4" or "mov r1, #1". > > Can anyone tell me why? You must be doing something wrong. probably the init sequences as performed by your BDI config file and those used in U-Boot conflict with each other. > My second question is how to program the u-boot to flash under BDI2000. See the BDI2000 user's Manual, and the DULG. > I've tried to program "u-boot" and "u-boot.bin" to 0x50000000 under BDI2000. > I can run it under BDI2000 by "go 0x50000000". But after I unplug the > BDI2000 from the Coyote board, it can't run (There's nothing on console). Is your boot device remapped to 0x50000000 on your board? Really? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de Each honest calling, each walk of life, has its own elite, its own aristocracy based on excellence of performance. - James Bryant Conant

2 1

[U-Boot-Users] Does ELDK support IXP425 (xscale)?
by Aric Wang 28 Jul '04

28 Jul '04

Does ELDK support IXP425 CPU? If so, where can I download it? thanks.

2 1

[U-Boot-Users] ARM946, u-boot and linux
by Shawn Jin 28 Jul '04

28 Jul '04

Hi, My next project will be on ARM946, a microprocessor without MMU. I'm totally a newbie to ARM processors though have experiences on porting u-boot and linux to several ppc processors. I am studying on how to set up the cross development environment. Please shed some light on these questions haunting me recently. 1. uclinux or linux? Since ARM946 has no MMU, uclinux might be a better starting point for porting linux to ARM946. But I have to find out the relationship between uclinux and linux. To my understanding, uclinux must be a patch to the normal linux distribution. 2. Boot loader? Does u-boot support ARM946? I know u-boot supports some ARM processors with MMU, such as 926. Or more general question: does u-boot support processors without MMU? From my ppc experience I know MMU is enabled on u-boot. 3. cross tool chain? Does ELDK support ARM946? ELDK supports arm920. ELDK can be used for arm946 if its core is compatible with arm920's. If ELDK doesn't support it, does it mean that I have to build the cross tool chain from scratch? Is there any off-shelf tool I can use? I tried to build ppc cross tool chain from scratch before the crosstool came into being. That's not a straightforward step, actually painful. Thank you very much! -Shawn.

2 3

[U-Boot-Users] how to program u-boot to flash?
by Aric Wang 28 Jul '04

28 Jul '04

Hello all, I compiled u-boot 1.1.1 under cygwin for Coyote board with "make ixdp425_config && make all". I use BDI2000 or Insight to load "u-boot" to the board. It runs well after I commented out below lines in "cpu/ixp/start. S": /* set EXP CS0 to the optimum timing */ ldr r1, =CFG_EXP_CS0 ldr r2, =IXP425_EXP_CS0 str r1, [r2] /* make sure flash is visible at 0 */ ldr r2, =IXP425_EXP_CFG0 ldr r1, [r2] orr r1, r1, #0x80000000 str r1, [r2] mov r1, #CFG_SDR_CONFIG ldr r2, =IXP425_SDR_CONFIG str r1, [r2] /* disable refresh cycles */ mov r1, #0 ldr r3, =IXP425_SDR_REFRESH str r1, [r3] /* send nop command */ mov r1, #3 ldr r4, =IXP425_SDR_IR str r1, [r4] DELAY_FOR 0x4000, r0 /* set SDRAM internal refresh val */ ldr r1, =CFG_SDRAM_REFRESH_CNT str r1, [r3] DELAY_FOR 0x4000, r0 /* send precharge-all command to close all open banks */ mov r1, #2 str r1, [r4] DELAY_FOR 0x4000, r0 /* provide 8 auto-refresh cycles */ mov r1, #4 mov r5, #8 111: str r1, [r4] DELAY_FOR 0x100, r0 subs r5, r5, #1 bne 111b /* set mode register in sdram */ mov r1, #1 str r1, [r4] DELAY_FOR 0x4000, r0 /* send normal operation command */ mov r1, #6 str r1, [r4] DELAY_FOR 0x4000, r0 If I don't comment out this, it will die on "mov r1, #4" or "mov r1, #1". Can anyone tell me why? My second question is how to program the u-boot to flash under BDI2000. I've tried to program "u-boot" and "u-boot.bin" to 0x50000000 under BDI2000. I can run it under BDI2000 by "go 0x50000000". But after I unplug the BDI2000 from the Coyote board, it can't run (There's nothing on console). Thanks in advance.

2 1

[U-Boot-Users] Re: Keeping Console on Serial after LCD Enabled
by Michael Bendzick 28 Jul '04

28 Jul '04

("Fake replying" since I can't find my original message as sent back to me by the listserv) I figured this issue out, and it was something in the code file that I was working with, though something I overlooked, not modified. --------------- Michael Bendzick wrote: With Himba"s help, I got things running much better for my OMAP 1510 Innovator LCD driver U-Boot, but once the LCD comes up (drv_lcd_init finishes), the serial console output is switched off. I can still issue commands from my serial console, and have them take effect (like changing a status LCD or turning off the LCD backlight with mm.b), but can"t see any more text output. I tried commenting out #ifdef CFG_DEVICE_NULLDEV memset (&dev, 0, sizeof (dev)); strcpy (dev.name, "nulldev"); dev.flags = DEV_FLAGS_OUTPUT | DEV_FLAGS_INPUT | DEV_FLAGS_SYSTEM; dev.putc = nulldev_putc; dev.puts = nulldev_puts; dev.getc = nulldev_input; dev.tstc = nulldev_input; device_register (&dev); #endif in common/devices.c, as when CONFIG_SPLASH_SCREEN is defined, CFG_DEVICE_NULLDEV gets defined, and would appear to reroute console output once assigned with dev.putc = serial_putc would now be dev.putc = nulldev_putc. However, this did not change the situation for me at all. Any ideas on how to maintain the serial terminal? Take note that my driver is very very similar to cpu/mpc8xx/lcd.c, so I do not expect that coding that I did is disabling the serial terminal, but instead some other interaction in the code is doing this. Thanks, -Michael Bendzick Systems and Software Engineering Logic Product Development michael.b@lo... 612-436-5122 <http://www.logicpd.com> -Michael Bendzick Systems and Software Engineering Logic Product Development michael.b(a)logicpd.com 612-436-5122 www.logicpd.com

2 1

[U-Boot-Users] Compact Flash Support in Uboot for MPC8540 ?
by Sudhakar 28 Jul '04

28 Jul '04

Hi , Is there any Compact Flash support[Boot level] for MPC8540 in U-boot.. If so plz provide me the details, My purpose was to write Diagnostics for Compact flash Thanks and Regards, Sudhakar

1 0

[U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c
by David Ho 28 Jul '04

28 Jul '04

Hi all, For those who are using an old u-boot version 0.4.8 like me please be warned that the code somehow is setting a register (spi->spi_rpbase) for which there is no defined behaviour (good or bad) when the spi ucode patch is _not_ applied. Apparently I hit on the bad behaviour where it just wouldn't work when spi_rpbase is set. void spi_init_f (void) { ... #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 */ #if THIS_IS_GIVING_ME_GRIEF spi->spi_rpbase = 0; #endif #endif I hope most of you would agree this is causing more harm then good. Regard, David Ho Nanometrics Inc.

2 5

[U-Boot-Users] Intel LXT972A on FADS 852T
by Knowledge Seeker 28 Jul '04

28 Jul '04

This is my second series of post on this subject. Current situation is that when I ping from uboot, now I do not get TX timeout, but get host is dead message. On tracing, I can tell that uboot successfully return from fec_send (it does get ok that packet was transmitted.) by reading TX descriptor. In fec_recv, it reads receive descriptor, and see no packet there. I have done of the obvious and non-obvious checks. e.g. ethernet cable and stuff outside the box is fully operational. Infect I see arp packet going out on ethereal. I know that reply is sent by the pinged box. I have read data sheet section of fec, and as far as I can tell, all the initialization is correct. I can talk to physical chip LXT972A, e.g. I can turn LEDs off and can set loopback mode, so that I am really talking to the chip. My hardware guy has checked all the clocks and he assures me that they are all in order. He also made external loopback, i.e. ethernet cable with input going to output, this also works. So what would be the cause of LXT972A not receiving anything. On LXT972A, I have checked configuration and status registers. On status register it says that nothing has been received.

2 5

[U-Boot-Users] Memory Map
by Knowledge Seeker 28 Jul '04

28 Jul '04

What is the suggested memory mapping of Flash and SDRAM. Kind in mind that altimate goal is to run Linux on this PPC 852T FADS board. Is following recommended Flash from 0x40000000 to 0x401000000 (16 mb) SDRAM from 0x00000000 to 0x002000000 (32 mb)

2 1

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?
by Michael Bendzick 27 Jul '04

27 Jul '04

I'm doing some development on a LCD framebuffer for the OMAP 1510 Innovator board (ARM925T CPU), and am encountering some difficulties with code flying off to strange places. I'm theorizing that the code flies off because memory is not properly allocated for the framebuffer. I'm basing all of my new U-Boot related code on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a final product. I make use of this code from lib_arm/board.c: #ifdef CONFIG_LCD /* * reserve memory for LCD display (always full pages) */ /* bss_end is defined in the board-specific linker script */ addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); size = lcd_setmem (addr); gd->fb_base = addr; #endif /* CONFIG_LCD */ I have a lcd_setmem function that works fine, but I don't think the memory map gets properly initialized once it knows how much framebuffer memory is needed. As the board initializes, "U-Boot code: 11080000 -> 1109D7B0 BSS: -> 110A1DA0" is printed, and the call lcd_setmem(0x110a2000) happens. lcd_setmem wants to reserve the size 0x13000, which causes 'addr' in the above code block to be 1108f000, and that is the location of the framebuffer. With the framebuffer occupying 1108f000 to 110A2000, that leaves only 1108000 to 1108f000 for U-Boot. Taking a look at disassembly of the binary, there is definitely valid code in the framebuffer range. I'm wondering how the code block above, which also appears in roughly the same form in lib_ppc/board.c, is supposed to grab a block of free memory for the framebuffer. Do I need to just allocate uchar framebuffer[col*row*depth+palette] and point the framebuffer address to that instead? Something else? Thanks, -Michael Bendzick Systems and Software Engineering Logic Product Development michael.b(a)logicpd.com 612-436-5122 www.logicpd.com

3 2

[U-Boot-Users] Keeping Console on Serial after LCD Enabled
by Michael Bendzick 27 Jul '04

27 Jul '04

With Himba's help, I got things running much better for my OMAP 1510 Innovator LCD driver U-Boot, but once the LCD comes up (drv_lcd_init finishes), the serial console output is switched off. I can still issue commands from my serial console, and have them take effect (like changing a status LCD or turning off the LCD backlight with mm.b), but can't see any more text output. I tried commenting out #ifdef CFG_DEVICE_NULLDEV memset (&dev, 0, sizeof (dev)); strcpy (dev.name, "nulldev"); dev.flags = DEV_FLAGS_OUTPUT | DEV_FLAGS_INPUT | DEV_FLAGS_SYSTEM; dev.putc = nulldev_putc; dev.puts = nulldev_puts; dev.getc = nulldev_input; dev.tstc = nulldev_input; device_register (&dev); #endif in common/devices.c, as when CONFIG_SPLASH_SCREEN is defined, CFG_DEVICE_NULLDEV gets defined, and would appear to reroute console output once assigned with dev.putc = serial_putc would now be dev.putc = nulldev_putc. However, this did not change the situation for me at all. Any ideas on how to maintain the serial terminal? Take note that my driver is very very similar to cpu/mpc8xx/lcd.c, so I do not expect that coding that I did is disabling the serial terminal, but instead some other interaction in the code is doing this. Thanks, -Michael Bendzick Systems and Software Engineering Logic Product Development michael.b(a)logicpd.com 612-436-5122 www.logicpd.com

1 0

RE: [U-Boot-Users] U-Boot Memory Allocation for Framebuffer?
by Michael Bendzick 27 Jul '04

27 Jul '04

Himba- I had actually noticed the that size from size = lcd_setmem wasn't getting used, and adjusted my own code to deal with that, it's just that I decided to paste from CVS instead of my own code for some reason. #ifdef CONFIG_LCD /* * reserve memory for LCD display (always full pages) */ /* bss_end is defined in the board-specific linker script */ addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); addr = lcd_setmem (addr); gd->fb_base = addr; #endif /* CONFIG_LCD */ ...is what I actually was using, which matched lib_ppc/board.c... /* round down to next 4 kB limit */ addr &= ~(4096 - 1); #ifdef CONFIG_LCD /* reserve memory for LCD display (always full pages) */ addr = lcd_setmem (addr); gd->fb_base = addr; #endif /* CONFIG_LCD */ In any case, I will give things a try with using the framebuffer at 0x110a2000. -Michael Bendzick -----Original Message----- From: himba [mailto:himba@siol.net] Sent: Tuesday, July 27, 2004 2:09 PM To: Michael Bendzick Cc: U-Boot-Users (E-mail) Subject: Re: [U-Boot-Users] U-Boot Memory Allocation for Framebuffer? Michael Bendzick wrote: > I'm doing some development on a LCD framebuffer for the OMAP 1510 Innovator > board (ARM925T CPU), and am encountering some difficulties with code flying > off to strange places. > > I'm theorizing that the code flies off because memory is not properly > allocated for the framebuffer. I'm basing all of my new U-Boot related code > on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a final > product. > > I make use of this code from lib_arm/board.c: > > #ifdef CONFIG_LCD > /* > * reserve memory for LCD display (always full pages) > */ > /* bss_end is defined in the board-specific linker script */ > addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); > size = lcd_setmem (addr); > gd->fb_base = addr; > #endif /* CONFIG_LCD */ > > I have a lcd_setmem function that works fine, but I don't think the memory > map gets properly initialized once it knows how much framebuffer memory is > needed. > If you look at the lcd_setmem() function in cpu/pxa/pxafb.c you can see that it does nothing worth calling it - maybe just for information that we are "reserving" FB mem. It just calculates the size, prints it out and does nothing else on that chunk. Also note that returned value by lcd_setmem() is not being used anywhere, for that matter. For my pxa255 arm target board I commented out call to lcd_setmem(). HTH, himba

2 1

[U-Boot-Users] how does stack work?
by Seingier François-Xavier 27 Jul '04

27 Jul '04

hello, I'm trying to understand how the initial stack works on a ppc4xx. According to start.S this is how the layout looks to me: ___________ | | | | | | | gd_t | |___________| | 0 | |___________| | 0 | |___________|<-+ | reset_vec | | SP ->|___________| | | |--+ |___________|<-+ | | | |___________| | | |--+ |___________| | ... | I can't figure out precisely how the last stack frame works: - /* clear final stack frame so that */ /* stack backtraces terminate cleanly */ I'm not sure to understand the "terminate cleanly". - why will the reset_vec be used in case of a stack underflow? I tried to find an answer in the "PowerPC compiler writer's guide" about the ABI, but I am not even sure gcc uses an AIX or System V implementation... If somebody could explain how this works in details, I would be very grateful (or point me to the right doc) Thanks in advance François-Xavier SEINGIER

2 1

RE: [U-Boot-Users] how does stack work?
by Seingier François-Xavier 27 Jul '04

27 Jul '04

sorry I did not put the SP at the right place on the figure ;)

1 0

[U-Boot-Users] uboot 1.1.1 reset and dataflash protection problem on AT91RM9200DK
by Aras Vaichas 27 Jul '04

27 Jul '04

I have two strange problems with uboot-1.1.1 on my AT91RM9200DK. 1) It will not pass the "uncompressing image" stage from power up, but if I remove the "Boot mode select link", press reset, replace the link, press reset, the system will begin to boot. sample output from problem 1) ** power on, nothing happens, press reset a few times to show a pattern "boot 1.0 (Jul 27 2004 - 09:42:33) Uncompressing image... boot 1.0 (Jul 27 2004 - 09:42:33) Uncompressing image... boot 1.0 (Jul 27 2004 - 09:42:33) Uncompressing image... ** remove jumper and press reset, CPU goes into self bootstrap mode CCCC ... ** replace jumper and press reset, u-boot starts working properly. boot 1.0 (Jul 27 2004 - 09:42:33) Uncompressing image... U-Boot 1.1.1 (Jul 27 2004 - 12:05:10) U-Boot code: 21F00000 -> 21F14530 BSS: -> 21F189D0 RAM Configuration: ... etc ... can boot Linux fine from this point onwards. 2) The system starts with the first half of dataflash protected. I keep unprotecting it, but when I reboot it still remains protected! Uboot> flinfo ... Area 0: C0000000 to C0007FFF (RO) Area 1: C0008000 to C001FFFF (RO) Area 2: C0020000 to C0027FFF Area 3: C0028000 to C083FFFF Uboot> protect off c0000000 c001ffff Un-Protect 2 DataFlash Sectors Uboot> flinfo ... Area 0: C0000000 to C0007FFF Area 1: C0008000 to C001FFFF Area 2: C0020000 to C0027FFF Area 3: C0028000 to C083FFFF ** reset (remove jumper, reset, replace jumper, reset ) U-Boot 1.1.1 (Jul 27 2004 - 12:05:10) ... Area 0: C0000000 to C0007FFF (RO) Area 1: C0008000 to C001FFFF (RO) Area 2: C0020000 to C0027FFF Area 3: C0028000 to C083FFFF Dataflash area is still read only!

2 1

Re: [U-Boot-Users] Heads up for ppl using the cpu/mpc8xx/spi.c
by David Ho 26 Jul '04

26 Jul '04

Okay since google search is down [the world is falling apart... arhh =)], I had the chance to look at the latest source and apparently it is still wrong. David

2 1

[U-Boot-Users] Protect Flash from tftpboot typos
by Konstantin Kletschke 26 Jul '04

26 Jul '04

Hi there! I wonder if there is a solution possible to Protect the FLASH Chip from typos. I have physikal Ram at 0x8000000 to 0x8FFFFFF and FLASH from 0x10000000 to 0x10FFFFFF. u-boot gets startet by the i.MX mechanism which maps the 1st MB of Flash to 0x0. The i.MX executes 1st command at 0x0 to 0xFFFFF tftpboot should only put downloaded images to RAM. I had a customer recently who put 130.1.2.3 as the 1st argument to tftpboot and tftpboot tries to put the image to 0x130. I also do typos there and an 0x0 as 1st Argument destroys contents of Flash though it is protected! I think an linux kernel Image for example contains code sequences who unlock, erase and write flash succesfully. I want to implement a mechanism which implements out of an config option a area where tftpboot acts (0x800000 to 0x8FFFFFF) and gives an error message otherway. Is that possible and where is the entry point in the code to put the funtkionality to? Regards, Konstantin Kletschke -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF

4 8

[U-Boot-Users] FYI: building u-boot image in cygwin environment fails
by Povolotsky, Alexander 26 Jul '04

26 Jul '04

-----Original Message----- From: Povolotsky, Alexander Sent: Friday, July 23, 2004 8:30 AM To: 'crossgcc(a)sources.redhat.com'; 'wd(a)denx.de' Cc: linuxppc-dev(a)lists.linuxppc.org Subject: FYI: building u-boot image in cygwin environment fails apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make MPC8260ADS_config Configuring for MPC8260ADS board... apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make all ............... make[1]: Entering directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/t ools' gcc -Wall -pedantic -D__WIN32__ -I../include -I.. -DTEXT_BASE=0xfff00000 -DUSE_H OSTCC -O -c -o img2srec.o img2srec.c In file included from img2srec.c:60: ../include/elf.h:46: warning: redefinition of `uint8_t' /usr/include/stdint.h:24: warning: `uint8_t' previously declared here ../include/elf.h:47: warning: redefinition of `uint16_t' /usr/include/stdint.h:25: warning: `uint16_t' previously declared here ../include/elf.h:48: error: conflicting types for `uint32_t' /usr/include/stdint.h:28: error: previous declaration of `uint32_t' make[1]: *** [img2srec.o] Error 1 make[1]: Leaving directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/to ols' make: *** [tools] Error 2

4 6