January 2006 - U-Boot

[U-Boot-Users] boot linux from memory
by Xuezhang Dong 25 Jan '06

25 Jan '06

I have u-boot work with memory only (my flash driver doesnot work yet), so I try to load linux to memory and give a try, but I find uImage have 40 bytes header, how I can boot linux by using u-boot command-line? Do I misunderstand something here? Following is what I did: ================================================== BRCM5001 # loadb 06008000 BRCM5001 # md 06008000 06008000: 27051956 39440bb6 43d6c107 000a01a8 '..V9D..C....... 06008010: 06008000 06008000 73966e28 05020200 ........s.n(.... 06008020: 4c696e75 782d322e 362e3135 00000000 Linux-2.6.15.... 06008030: 00000000 00000000 00000000 00000000 ................ 06008040: e1a00000 e1a00000 e1a00000 e1a00000 ................ 06008050: e1a00000 e1a00000 e1a00000 e1a00000 ................ 06008060: ea000002 016f2818 00000000 000a01a8 .....o(......... 06008070: e1a07001 e3a08000 e10f2000 e3120003 ..p....... ..... 06008080: 1a000001 e3a00017 ef123456 e10f2000 ..........4V.. . 06008090: e38220c0 e121f002 ee110f10 e3800080 .. ..!.......... 060080a0: ee010f10 00000000 00000000 00000000 ................ 060080b0: 00000000 00000000 00000000 00000000 ................ 060080c0: e28f00c8 e890307e e0500001 0a00000a ......0~.P...... 060080d0: e0855000 e0866000 e08cc000 e0822000 ..P...`....... . 060080e0: e0833000 e08dd000 e5961000 e0811000 ..0............. 060080f0: e4861004 e156000c 3afffffa e3a00000 .....V..:....... ================================================== If I try to boot from 06008000, I got following: BRCM5001 # bootm 06008000 ## Booting image at 06008000 ... Image Name: Linux-2.6.15 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 655784 Bytes = 640.4 kB Load Address: 06008000 Entry Point: 06008000 Verifying Checksum ... OK XIP Kernel Image ... OK Starting kernel ... undefined instruction pc : [<06008004>] lr : [<06f8c324>] sp : 06f3fb58 ip : 00000001 fp : 00000002 r10: 00000002 r9 : 06f3fcf4 r8 : 06f3ffdc r7 : 06f9082c r6 : 06f8d744 r5 : 06f9082c r4 : 00000000 r3 : 06008000 r2 : 00000100 r1 : 000001c4 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32as for 'help' auto Resetting CPU ... ================================================== If I try to jump the header, I got following: BRCM5001 # go 06008040 ## Starting application at 0x06008040 ... Uncompressing Linux............................................. done, booting t he kernel. Thanks for any advice. Regards. Xuezhang.

2 1

[U-Boot-Users] uboot doubts ?
by Maximus 25 Jan '06

25 Jan '06

Hi, I am using u-boot. i want to write my own protocol and add a few commands to u-boot for my custom board. I want to send packets and recieve packets (UDP). I followed the example as given in tftp.c and am able to send packets. using NetSendUDPPacket. I did not understand the following: 1) What do the following do ?. NetSetTimeout (TIMEOUT * CFG_HZ, TftpTimeout); NetSetHandler (TftpHandler); All i could make sense it after the timeout, TftpTimeout is called. Is it called under all circumstances or only based on specific circumstances. ( Say if i get a packet. i may not want it to be called). i could not understand beyound this. What is the precision of the timeout value. are milliseconds allowed ? Am i right ?. Why do we require an handler. what does NetStartAgain ( ) do ?. Where does it start again ?. if i want to use it - what should i keep in mind. any variables need to be taken care of ?. 2) What does NetState variable in net.c do ? I could manage to write a send routine. but recieve i am not able to understand the code. I just want to recieve packets and take some actions (just like a server). are there any examples for doing this. suppose i dont get a packet say within 1 sec. i may want to do some other thing ?. is it possible in u-boot. I am a dull idiot. I dont understand easily. Please be elaborate in your answers. Thanks for Your time. i would appreciate any responses. Thanks once again. With Warm Regards, John.

1 0

[U-Boot-Users] [PATCH] Two System ACE CF fixes
by Peter Ryser 25 Jan '06

25 Jan '06

Attached a patch that adds support for the 16-bit wide bus of System ACE CF besides the existing support for the 8-bit wide bus. The patch also sets the FORCECFGMODE bit in the control register when the System ACE CF configuration controller is reset before reading a sector. Without this bit set System ACE CF reconfigures an FPGA if the CFGMODE pin is active whenever a sector is read. The third hunk fixes a typo. - Peter --- u-boot.orig/common/cmd_ace.c 2005-09-22 23:53:00.000000000 -0700 +++ u-boot/common/cmd_ace.c 2005-09-26 07:40:41.000000000 -0700 @@ -22,8 +22,9 @@ /* * The Xilinx SystemACE chip support is activated by defining * CONFIG_SYSTEMACE to turn on support, and CFG_SYSTEMACE_BASE - * to set the base address of the device. This code currently - * assumes that the chip is connected via a byte-wide bus. + * to set the base address of the device. CFG_SYSTEMACE_WIDTH + * selects the bus width the chip is connected with. Valid + * settings are 8 or 16. * * The CONFIG_SYSTEMACE also adds to fat support the device class * "ace" that allows the user to execute "fatls ace 0" and the @@ -137,6 +138,11 @@ block_dev_desc_t * systemace_get_dev(in systemace_dev.removable = 1; systemace_dev.block_read = systemace_read; + if(CFG_SYSTEMACE_WIDTH == 8) + ace_writew(0, 0); + else + ace_writew(1, 0); + init_part(&systemace_dev); } @@ -227,7 +233,7 @@ static unsigned long systemace_read(int /* Reset the configruation controller */ val = ace_readw(0x18); - val|=0x0080; + val|=0x0088; ace_writew(val, 0x18); retry = trans * 16; @@ -249,7 +255,7 @@ static unsigned long systemace_read(int retry -= 1; } - /* Clear the configruation controller reset */ + /* Clear the configuration controller reset */ val = ace_readw(0x18); val&=~0x0080; ace_writew(val, 0x18); * Add System ACE CF support for 16-bit bus width Add fix to ignore CFGMODE pin when resetting the System ACE CF configuration controller to avoid reconfiguration of FPGAs when reading sectors. Patch by Peter Ryser, 26 Sep 2005

2 2

[U-Boot-Users] IXP425 processor
by Frank 25 Jan '06

25 Jan '06

Does the EDK4.0 cross toolchain support the IXP425 Xscale processor? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[U-Boot-Users] SDRAM is almost done
by ronen ronen 25 Jan '06

25 Jan '06

1 0

[U-Boot-Users] Das U-Boot applications and ELDK 4.0 breakage
by Bryan O'Donoghue 24 Jan '06

24 Jan '06

Greetings. The following code breaks U-Boot applications with ELDK 4.0 and presumably with reasonably recent gcc toolchains, though not with ELDK 3.1.1 #include <common.h> #include <commproc.h> static void function_1(); /* int bug_test(int argc, char * argv[]) __attribute__ ((section (".text.uboot"))); */ int bug_test(int argc, char * argv[]) { app_startup(argv); printf("Startup\n"); function_1(); function_1(); return 0; } static void function_1() { printf("%s\n", __FUNCTION__); return; } Compling this for powerpc yeilds bethany@SlackwareBabe:~/devel/DasUBoot$ ppc_8xx-gdb examples/bug_test GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh) <snip> (gdb) disass 0x40004 Dump of assembler code for function function_1: 0x00040004 <function_1+0>: stwu r1,-16(r1) 0x00040008 <function_1+4>: mflr r0 0x0004000c <function_1+8>: bcl- 20,4*cr7+so,0x40010 <function_1+12> 0x00040010 <function_1+12>: stmw r30,8(r1) 0x00040014 <function_1+16>: mflr r30 0x00040018 <function_1+20>: stw r0,20(r1) 0x0004001c <function_1+24>: lwz r0,-16(r30) 0x00040020 <function_1+28>: add r30,r0,r30 0x00040024 <function_1+32>: lwz r3,-32768(r30) 0x00040028 <function_1+36>: lwz r4,-32764(r30) 0x0004002c <function_1+40>: bl 0x400ec <printf> 0x00040030 <function_1+44>: lwz r0,20(r1) 0x00040034 <function_1+48>: lmw r30,8(r1) 0x00040038 <function_1+52>: mtlr r0 0x0004003c <function_1+56>: addi r1,r1,16 0x00040040 <function_1+60>: blr End of assembler dump. bethany@SlackwareBabe:~/devel/DasUBoot$ ppc_8xx-gcc -v <snip> gcc version 4.0.0 (DENX ELDK 4.0 4.0.0) Compiling with ELDK 3.1.1 or simply calling function_1() just once in bug_test will result in the function bug_test being linked to 0x40004 as expected. If I'm right what is happening is that the placement of functions in the text section has changed behaviour between toolchain versions and gcc now will optimise placement of functions/variables in sections. I have tried messing about with various __attribute__ ((section ("x"))) promulgations to get around the fact that we are expecting the function bug_test to be present at 0x40004. The only reliable way to do that is to specify to gcc -fno-unit-at-a-time during compile time. Apparently this prevents gcc from parsing the entire file before starting to generate assembler and consequently produces bug_test at the address 0x40004 as expected. While -fno-unit-at-a-time wouldn't be _too_ bad, the gcc manual states that -fno-unit-at-a-time may not be supported in future releases and code that cares about the address of variables/functions should use explicate section attributes ! I haven't been able to figure out how to tell ld to create a "subsection" in the text section and to put ".text.uboot" at a specific address above. For example -Ttext=0xblah --section-start=.uboot.text=0xblah completely ignores the --section-start and puts bug_test where *ld* thinks it should go. Possibly one could apply an __attribute__ ((section (".uboot_entry"))) qualifier to a function and the Makefile could say something like --section-start=.uboot_entry=0x40000 -Ttext=0x50000 but, that's probably a little naff and make assumptions about how big your code will be. This mightn't be a bug that's even worth fixing, i.e. the number of people who a) write applications and b) make multiple calls to locally defined functions in U-Boot probably numbers at 1 ! In any case I'm a linker script newbie so perhaps there is a simple/obvious/easy fix for this that I'm just missing, apologies if that is the case. Greetings, Happy new year, etc. Bryan -- "Caveat Emptor" -- James T. Kirk, in no such episode

1 0

[U-Boot-Users] Problem getting code from git repository
by Marty ＠ GMail 24 Jan '06

24 Jan '06

I attempted to retrieve the U-Boot code from the repository and got the following. Any suggestions?? I am also getting a similar problem trying to retrieve the Linux 2.6 code. wedepohl@ubuntu:/opt2/eldk/ppc_6xx/usr/src$ cg-clone http://www.denx.de/git/u-boot.git u-boot.git defaulting to local storage area 11:15:12 URL:http://www.denx.de/git/u-boot.git/refs/heads/master [41/41] -> "refs/heads/origin" [1] progress: 9 objects, 122484 bytes error: File 73d9625beadea1a39a4073f95da9be2f944806a8 (http://www.denx.de/git/u-boot.git/objects/73/d9625beadea1a39a4073f95da9be2f…) corrupt Cannot obtain needed blob 73d9625beadea1a39a4073f95da9be2f944806a8 while processing commit 0000000000000000000000000000000000000000. error: cannot map sha1 file 73d9625beadea1a39a4073f95da9be2f944806a8 cg-pull: objects pull failed cg-init: pull failed wedepohl@ubuntu:/opt2/eldk/ppc_6xx/usr/src$

1 0

[U-Boot-Users] bd_t structure
by Frank 24 Jan '06

24 Jan '06

I've ported a 2.4.x kernel from a ppc405EP based board to 2.6.15 but I am having problems with the bd_t info passed from the boot loader. i am trying to use the original ppcboot (yes i know it's old but I don't to port it right now) to boot the 2.6.15 kernel. It looks like the board information passed to ppc4xx_init in r3 is not the same. I also looked at the ppcboot.h file in the 2.6 kernel and it doesn't appear to be the same as the one in the ppcboot source tree. My question is: can I boot a kernel made with the 2.6.15 tree with ppcboot instaed of u-boot? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 5

[U-Boot-Users] [Patch] Add addr2ram function for AT91RM9200
by Lacressonniere Nicolas 24 Jan '06

24 Jan '06

That patch adds addr2ram function in cpu/arm920t/at91rm9200dk.c. It is needed by do_mem_cp function in cmd_mem.c (added by the AT91SAM9261 DataFlash patch). That function simply verifies if address is in SDRAM address space or not. CHANGELOG Patch by Nicolas Lacressonniere 24 January 2006 * Add addr2ram verification function for at91rm9200dk

2 1

[U-Boot-Users] max gunzip output buffer size in do_bootm()
by Matthias Fuchs 24 Jan '06

24 Jan '06

Hi, I ran into trouble when booting huge compressed images via bootm. do_bootm uses a fixed maximum size for the uncompressed data of 0x400000 bytes. That's not enough for our images (about uncompressed 9MB VxWorks image). Is there any reason for the 4MB limiting? I'd like to post a patch that fixes this issue: a) just increase the unc_len variable to e.g. 16MB b) add a define with default to board config file (CONFIG_MAX_BOOTM_UNC_LEN). When not defined in config file, 0x400000 is used c) set unc_len to mem size :-) So user must know what he is doing. What do you like best? BTW: When the uncompressed data is more than the unc_len limit no error is reported. The uncompressed data is just truncated leading to corrupted uncompressed data. Should that be fixed, too? Regards Matthias

2 1