March 2009 - U-Boot

[U-Boot] U-Boot 1.1.6 and Marvell 88E1116 RGMII operations
by Ray Fogg 04 Mar '09

04 Mar '09

My company is in the process of bringing up a new MPC8347-based product. A previous product utilized the same processor and a 100mbit GMII PHY and ran with U-Boot 1.1.6. The new board utilizes a Marvell 88E1116 PHY, and to keep things as simple as possible and to stay with the same Linux kernel that we have used, we are trying to stay with 1.1.6. We appear to recognize the PHY correctly, and achieve link. We can place the PHY in packet generation mode and see that it properly sends data out the cable. But a ping command from U-Boot results in no traffic on the cable, leading us to the suspicion that the MAC is not properly set up in RGMII mode. We note that the newest release of U-Boot supports the Marvell 88E1118 PHY, which uses the same die as the 88E1116. Our question is: has anyone made the 88E1116 or the 88E1118 work using U-Boot version 1.1.6, or are there any suggestions on making this work? -- Ray Fogg Tyzx, Inc 503-693-0863

2 1

Re: [U-Boot] Alignment bug in itest on ARM & doesn't work on big-endian either?
by Tom Evans 04 Mar '09

04 Mar '09

Jean-Christophe PLAGNIOL-VILLARD <plagnioj(a)jcrosoft.com> wrote: > On 17:40 Tue 03 Mar , Tom Evans wrote: >> BUG IN ITEST >> ------------ >> itest crashes ARM chips. I can "iread.b *82000000 == 0", >> but "iread.b *82000001 == 0" throws an alignment >> exception that kills the box. The code in itest.c is: >> >> static long evalexp(char *s, int w) >> { >> long l, *p; >> >> /* if the parameter starts with a * then assume >> is a pointer to the value we want */ >> if (s[0] == '*') { >> p = (long *)simple_strtoul(&s[1], NULL, 16); >> l = *p; > here you are support to use the good accessor > readb/readw/readl Thank you for your response. readl() is defined in asm-arm/io.h as "__arch_getl(a)" which is defined as "(*(volatile unsigned int *)(a))" which doesn't handle misalignment and will still crash. I think those functions are only meant for I/O reads. The code then "selects the byte" with the following: >> return (l & ((1 << (w * 8)) - 1)); That selects the LOWER 8/16/32 bits of the 32-bit read. Which works on a 486, ARM variants with unaligned transfers, but NOT on a PPC or any other big-endian CPUs (about half of them supported by U-Boot). On a big-endian unaligned supporting CPU I'd expect a byte read of address "0" to read "3" and a read of "1" to read "4" (in the next word!). Ditto for itest.w. Whoever owns/maintains this code, and/or can test it on a big-endian target should fix these, taking hints from the cmd_mem.c code which does all of this in a portable manner. I don't have a big-endian target so I can't test the big-endian fix. > the arm does not allow you to do an non aligned access I know that. The current itest code doesn't. The "indirect pointer feature" mustn't be used much if I'm the first one to find these problems. -- === Tom Evans Tom.Evans(a)ceos.com.au CEOS Pty Ltd www.ceos.com.au 3/17 Burgundy St, Heidelberg, Victoria 3084, Australia

1 0

[U-Boot] [PATCH] Reduce OneNAND IPL common code (v3)
by Kyungmin Park 04 Mar '09

04 Mar '09

OneNAND IPL has common codes for RAM init, load data, and jump to 2nd bootloader, but it's common code used about 300~400 bytes. So board specific codes, such as lowlevel_init, can't has enough code. It make a difficult to implement OneNAND IPL. his patch make this common code as small as possible. and give lowlevel_init can have more codes. Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- diff --git a/cpu/arm1136/start.S b/cpu/arm1136/start.S index e622338..c115003 100644 --- a/cpu/arm1136/start.S +++ b/cpu/arm1136/start.S @@ -33,23 +33,7 @@ .globl _start _start: b reset #ifdef CONFIG_ONENAND_IPL - ldr pc, _hang - ldr pc, _hang - ldr pc, _hang - ldr pc, _hang - ldr pc, _hang - ldr pc, _hang - ldr pc, _hang - -_hang: - .word do_hang - .word 0x12345678 - .word 0x12345678 - .word 0x12345678 - .word 0x12345678 - .word 0x12345678 - .word 0x12345678 - .word 0x12345678 /* now 16*4=64 */ + . = _start + 64 #else ldr pc, _undefined_instruction ldr pc, _software_interrupt @@ -362,12 +346,7 @@ cpu_init_crit: /* * exception handlers */ -#ifdef CONFIG_ONENAND_IPL - .align 5 -do_hang: - ldr sp, _TEXT_BASE /* use 32 words about stack */ - bl hang /* hang and never return */ -#else /* !CONFIG_ONENAND IPL */ +#ifndef CONFIG_ONENAND_IPL .align 5 undefined_instruction: get_bad_stack diff --git a/onenand_ipl/onenand_boot.c b/onenand_ipl/onenand_boot.c index aff62d2..04735e7 100644 --- a/onenand_ipl/onenand_boot.c +++ b/onenand_ipl/onenand_boot.c @@ -28,54 +28,17 @@ #include "onenand_ipl.h" -#ifdef CONFIG_SYS_PRINTF -int print_info(void) -{ - printf(XLOADER_VERSION); - - return 0; -} -#endif - typedef int (init_fnc_t)(void); -init_fnc_t *init_sequence[] = { - board_init, /* basic board dependent setup */ -#ifdef CONFIG_SYS_PRINTF - serial_init, /* serial communications setup */ - print_info, -#endif - NULL, -}; - void start_oneboot(void) { - init_fnc_t **init_fnc_ptr; uchar *buf; - for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { - if ((*init_fnc_ptr)() != 0) - hang(); - } - buf = (uchar *) CONFIG_SYS_LOAD_ADDR; - if (!onenand_read_block0(buf)) - buf += ONENAND_BLOCK_SIZE; - - if (buf == (uchar *)CONFIG_SYS_LOAD_ADDR) - hang(); + onenand_read_block0(buf); - /* go run U-Boot and never return */ - printf("Starting OS Bootloader...\n"); ((init_fnc_t *)CONFIG_SYS_LOAD_ADDR)(); /* should never come here */ } - -void hang(void) -{ - /* if board_hang() returns, hange here */ - printf("X-Loader hangs\n"); - for (;;); -} diff --git a/onenand_ipl/onenand_ipl.h b/onenand_ipl/onenand_ipl.h index 3387998..57e54f5 100644 --- a/onenand_ipl/onenand_ipl.h +++ b/onenand_ipl/onenand_ipl.h @@ -23,12 +23,6 @@ #include <linux/mtd/onenand_regs.h> -#define ONENAND_BLOCK_SIZE 2048 - -#ifndef CONFIG_SYS_PRINTF -#define printf(format, args...) -#endif - #define onenand_readw(a) readw(a) #define onenand_writew(v, a) writew(v, a)

2 1

[U-Boot] Status open patches: ColdFire
by Wolfgang Denk 03 Mar '09

03 Mar '09

Dear John & Tsi Chung, I have the following patches still marked as open in my list. Could you please have a look... ColdFire: 12/04 "arun c" [U-Boot] [PATCH] Coldfire: XL Bus minor fixes Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence. - W. K. Clifford, British philosopher, circa 1876

2 1

[U-Boot] Uboot and DMA
by praveen G 03 Mar '09

03 Mar '09

Hi, Please let me know if Uboot uses DMA for any of its operations during board bootup. Please let me know if Uboot has DMA support and if yes how?? Thanks in advance. Best Regards, Nikhil

2 3

Re: [U-Boot] AT91RM9200 U-Boot can not load initrd from flash
by Dmitry K 03 Mar '09

03 Mar '09

> To be more precise: Patches to the Linux kernel have been submitted... > I've searched archive using gmane but found only links to cvs whis is no longer used. This question seems to be asked frequently, so why don't you add it to FAQ along with link to patches to prevent further questions? Thank you -- Dmitry K.

1 0

[U-Boot] AT91RM9200 U-Boot can not load initrd from flash
by Dmitry K 03 Mar '09

03 Mar '09

Hello I've a board quite similar to AT91RM9200DK. I've compiled U-Boot 1.1.2 and 1.3.4 for it and both work fine with images loaded via tftp. When I try to boot same images from flash I got kernel running fine until this: ... No filesystem could mount root, tried: ext2 cramfs vfat romfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Seems like initrd is not copied to RAM by U-Boot. The u-boot environment is: setenv ipaddr 192.168.1.1 setenv serverip 192.168.1.10 setenv bootargs 'root=/dev/ram rw initrd=20a00000,500000 ramdisk_size=8192 console=ttyS0,115200 mem=32M mtdparts=phys_mapped_flash:64K(boot),64K(uboot),2944K(kernel),4608K(initrd),256K(settings),-(unused)' setenv bootcmd "bootm 10020000 10300000" The images are: U-Boot> imls Legacy Image at 10020000: Image Name: K_2009-01-12_13:47:42 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2443456 Bytes = 2.3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Legacy Image at 10300000: Image Name: FS_2009-01-12_14:13:24 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3446369 Bytes = 3.3 MB Load Address: 20a00000 Entry Point: 20a00000 Verifying Checksum ... OK What am I missing? -- Dmitry K.

3 5

[U-Boot] Is it possible to support interrupts in ARM without MMU in u-boot
by akshay st 03 Mar '09

03 Mar '09

Hi, I wanted to know whether it is possible to support arm interrupts in u-boot without MMU on. Since ARM expects the normal interrupt vectors to be either 0x00000000 or 0xffff00000. If possible can be tell me what needs to be done? Warm Regards, Akshay Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/

1 0

[U-Boot] FSL DDR @ 83xx
by Andre Schwarz 03 Mar '09

03 Mar '09

Kim, I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board. This implies using a fake SPD and the related code to set up the controller. Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ? regards, André MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

5 12

[U-Boot] U-Boot Scripting suggestions to decrement counter in EEPROM. Alignment bug in itest on ARM.
by Tom Evans 03 Mar '09

03 Mar '09

I'm implementing a rather complex boot that involves flags and counters in EEPROM. This is to detect multiple boot failures and to then revert to a previous Linux kernel and sysroot. The Hush shell and applications almost support this by using scripts (even autoscripting), but not quite. "ee read" and "ee write" let me read and write the counters and flags to memory. From there, "if itest *$buf_addr == 1" (and so on) can be used to test the values of flags in the EEPROM (except for bad bug in itest, listed later). "mw.b" can write flags into memory to then be written to eeprom. The only way I can currently think of to "read" a byte from EEPROM into a shell variable so it can be decremented (with setexpr) and then written back is to use something like the following: READ_ADDR=0x82000000 setenv FN_READ_BYTE 'setenv DATA; DATA=0; while itest \ *$READ_ADDR != $DATA; do setexp DATA $DATA + 1; done' mw.l 0x82000000 254 run FN_READ_BYTE echo $DATA Yes, it is comparing every value from zero and incrementing until it gets a match! That results in $DATA being set to "254" (the value I wrote to memory) but it takes 9 seconds to run on an 800MHz ARM core! Am I missing a simpler way or am I going to have to add some new commands, like a "memory read" variant that reads into an environment variable. If setexpr took a "*" to be a pointer (to be consistent with itest) it might be the easiest addition. BUG IN ITEST ------------ itest crashes ARM chips. I can "iread.b *82000000 == 0", but "iread.b *82000001 == 0" throws an alignment exception that kills the box. The code in itest.c is: static long evalexp(char *s, int w) { long l, *p; /* if the parameter starts with a * then assume is a pointer to the value we want */ if (s[0] == '*') { p = (long *)simple_strtoul(&s[1], NULL, 16); l = *p; } else { l = simple_strtoul(s, NULL, 16); } return (l & ((1 << (w * 8)) - 1)); } "l = *p" works on a 486 but not on an ARM. It is a simple change - a three-way case on the width reading through the "right pointer". Yes, I should fix this and submit a patch, but I'm not working on anything close to the distribution tree unfortunately. I'm pretty sure this hasn't been fixed lately though. -- === Tom Evans Tom.Evans(a)ceos.com.au CEOS Pty Ltd www.ceos.com.au 3/17 Burgundy St, Heidelberg, Victoria 3084, Australia

2 1