July 2005 - U-Boot

[U-Boot-Users] about do_bootm_linux in cmd_bootm.c
by zhuzhenhua 04 Jul '05

04 Jul '05

i used u-boot to run kernel,and it only stoped at "starting kernel...",so i add some prinft command in cmd_bootm.c as follow: do_bootm() { .... switch (hdr->ih_os) { default: /* handled by (original) Linux case */ case IH_OS_LINUX: #ifdef CONFIG_SILENT_CONSOLE fixup_silent_linux(); #endif printf("befor do_bootm_linux \n"); \\added by myself do_bootm_linux (cmdtp, flag, argc, argv, addr, len_ptr, verify); printf("after do_bootm_linux \n"); \\added by myself break; } do_bootm_linux() {... void (*kernel)(bd_t *, ulong, ulong, ulong, ulong); printf("enter the do_bootm_linux \n"); image_header_t *hdr = &header; } but i run get as follow ...... befor do_bootm_linux Starting kernel ... so if it can not run to printf("enter the do_bootm_linux \n"), where it puts the "Starting kernel ..." thanks for any hints zzhhust

2 1

[U-Boot-Users] USB support from U-Boot for the AT91RM9200
by Neil Bryan 04 Jul '05

04 Jul '05

Hello group, I have searched the mailing list and know this question has been asked before, but it was six months ago and the situation may have changed. Has anyone added USB-support for the ATMEL AT91RM9200 in U-boot but has not sent the changes to be intergrated into U-Boot? I have checked the CVS-head and cannot see support for USB, so I presume it is not there. However, before I embark on a long and painful battle, I thought I would ask! Thanks in advance, Neil.

2 2

Re: [U-Boot-Users] u-boot on OSK
by Wolfgang Denk 04 Jul '05

04 Jul '05

Hello, please keepo the list Cc:ed so others can benefit from this, too. In message <764af189050704012577893eda(a)mail.gmail.com> you wrote: > > I want to divide my flash into two parts and the two parts should be > independent of each other. My question is this one. One partition i am > planning to use for linux and the second for some other OS. So i want > the two parts to be independent. _Creating partitions on the flash is something which effects only the operating system(s) you are going to use. No special changes to U-Boot are needed for this. > In the flash.c file of omap5912osk the function flash_get_size is > wrinting some values to the 0x5555, 0x2AAA and 0x5555 locations. Do i > have to do the same thing for my second partition also? U-Boot operates on the whole physical flash memory, without knowing anything how an OS might interpret the data in the flash, and without having any notation of partitions or the like. > Where can i specify the starting and ending addresses for my two partitions= > ? You cannot, but this is no problem, as you don't have to. There is no part in U-Boot where such information is needed. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de In a business, marketroids, salespukes, and lawyers have different goals from those who actually do work and produce something. Usually, is is the former who triumph over the latter, due to the simple rule that those who print the money make the rules. -- Tom Christiansen in <5jdcls$b04$2(a)csnews.cs.colorado.edu>

1 0

[U-Boot-Users] AT91RM9200EK erase ATMEL dataflash
by S. Dikhoff 04 Jul '05

04 Jul '05

Hi, I use u-boot-1.1.2 on an AT91RM9200EK board. Does anybody knows how to erase the dataflash which is connected to the SPI? I tried: U-Boot1.1.2 > flinfo DataFlash:AT45DB642 Nb pages: 8192 Page Size: 1056 Size= 8650752 bytes Logical address: 0xC0000000 Area 0: C0000000 to C0007FFF Area 1: C0008000 to C001FFFF Area 2: C0020000 to C0027FFF Area 3: C0028000 to C083FFFF U-Boot1.1.2 > protect off c0000000 c001ffff Un-Protect 2 DataFlash Sectors U-Boot1.1.2 > erase c0000000 c001ffff Error: start and/or end address not on sector boundary The copy of images with "cp.b" to this flash seems to work properly, even without erasing the flash before. Regards Sascha

2 1

[U-Boot-Users] u-boot on OSK
by Naveen Atmakuri 04 Jul '05

04 Jul '05

Hi all, I am using u-boot-1.1.2 on my OSK board to boot linux. But my final application wants me to divide the flash in to two banks of 16M each. Is there any patch available to do this. Or else can any one guide me how to do it my self, as i am new to this u-boot. From the souce I came to know that while initialization of the flash it is checking for the vendor and device id. If i have to divide my flash in to two banks what are all the files that i have to modify. Thanks in advance, Naveen

2 1

[U-Boot-Users] Phy and Flash detection on ATMEL RM9200 EK based board
by Stage Iup - Fabrice & Frederic 04 Jul '05

04 Jul '05

Hi all i'm actually trying to use U-boot on my board that is based on the RM9200EK from Atmel so when i configure it, i use the at91rm9200_config option but due to the fact that the Flash chip and the PHY chip are different they are not detected. I'm using a AT49BV6416T (AT49BV6416 on the board from Atmel) and an Intel LXT971ALE A4 (Davicom on the board) So does any body have an idea on how about to make these chips detected? For the Flash Chip i've change the device id to go with the T flash (#define ATM_ID_BV6416 0x000000D6 >>> #define ATM_ID_BV6416 0x000000D2 in the flash.hfile) and the flash organization ( OrgDef OrgAT49BV6416[] ={ { 8, 8*1024 }, { 127, 64*1024 },}; >>> OrgDef OrgAT49BV6416[] ={ { 127, 64*1024 }, { 8, 8*1024 },};) with regards -- Frédéric Kwiatkowski -- Plateforme Technologique Valence Tél : 04 75 41 88 58

1 0

[U-Boot-Users] Support for MPC8343E
by Dmytro Bablinyuk 04 Jul '05

04 Jul '05

I expect to have eval board soon for above beast. Could anyone give me an idea of at what stage current U-boot support for MPC8343E or what the closest configuration I may use. Thank you

1 0

[U-Boot-Users] cfi_flash is now working with 64 bit port width
by Yusuf Ibrahim Ozkok 02 Jul '05

02 Jul '05

Hi, I have resolved my problem with cfi_flash driver. I would like to share what I have learned during my struggle with cfi_flash driver. The posts for that problem; http://sourceforge.net/mailarchive/message.php?msg_id=11994639 http://sourceforge.net/mailarchive/message.php?msg_id=12058552 What caused the problem and how is it solved: Flash chips in my board are connected to 64 bit data bus. And the problem is simply about writing 64 bit data at once. cfi_flash driver used "unsigned long long" variables for 64 bit data and write them to the bus simply using long long pointers (For me that is a bug. And I would like to release a patch for it). Any integer definition (like int, long, long long etc.) makes gcc to use 32 bit registers of the cpu (for 32 bit ppc's). Long long is 64 bit on the memory that is true, but transfering a long long requires two cycles. To write a 64 bit data at once we have to use floating point registers. A way of using these registers in C is to define the variables as "double". But somehow defining double didn't work in u-boot or with my ppc_82xx-gcc compiler (eldk's compiler). An other way is to use assembly floating point instructions but double precision forms. Such as "lfd" and "strfd" commands for ppc have to be used. Jerry Van Baren had warned me previously but I couldn't make sense with his suggestions at the moment. What make me confused that writing flash commands from u-boot shell by using mw.l command was working for protect and erase operations. Since mw.l makes 32 bit bus transaction, for example a 0x60606060 command was beeing recognized by all the four flash chips. On the other way a 0x00600060 command is caused failure (I had expected that it will work two out of four flash chips). Now when I solved the problem by using floating point registers, I understood Jerry's suggestions exactly! You can reach his post by the link. (http://sourceforge.net/mailarchive/message.php?msg_id=11994640) But I still can not solve the magic that while sending 0x60606060 by mw.l command works but 0x00600060 not! Lessons: So lesson-1: if hardware people gives you a 64 bit bus, use double or directly asm floating point instructions. I think cfi_driver works with the boards that the flash chips are selected by chip select signals for each 32 bit portion of the data bus. In our board all the flash chips are connected to the same chip select signal that caused the problem. Lesson-2: first of all examine your hardware well and be aware of your hardware. Thanks for your help: Jerry Van Baren, Yuli Barcohen, Richard Woodruff. The patch (unformatted): 1. The following function is added. static void write_via_fpu (vu_long * addr, ulong * data) { __asm__ __volatile__ ("lfd 1, 0(%0)"::"r" (data)); __asm__ __volatile__ ("stfd 1, 0(%0)"::"r" (addr)); } 2. in /drivers/cfi_flash.c line 850; - *addr.llp = cword.ll; + write_via_fpu((vu_long*)addr.llp, (ulong*)&cword.ll); line 1159; - cptr.llp[0] = cword.ll; + write_via_fpu((vu_long*)cptr.llp, (ulong*)&cword.ll); P.S. this function will work if fpu is enabled. If not it may be enabled by setting the fpu bit in msr as follows; unsigned long msr; msr = get_msr(); set_msr(msr | MSR_FP); *_msr functions may be found by grepping the uboot directory. 3. The patch is not tested when CFG_FLASH_USE_BUFFER_WRITE is defined. Same changes as in 2 should be done for that case. If those changes are accepted, I can arrange a formal patch. Finally, I would like to ask about the Tolunay Orkun's patch about tout in flash_status_check function. what is the last thought for that patch Is it planned to be released? Because it's really a bug! (Last post for the thread; http://sourceforge.net/mailarchive/message.php?msg_id=11936556) Best Wishes. Yusuf. ###################################################################### Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi gorusu olmak zorunda degildir. ###################################################################### Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any views or opinions presented are solely those of the author and do not necessarily represent the views of the company. ######################################################################

5 8

[U-Boot-Users] PCI video display in MPC8270
by Maynard Cabiente 02 Jul '05

02 Jul '05

Hi All, We currently just enabled the PCI bus on our MPC8270 custom board. We intend to put a video chip in the PCI bus (XGI Volari Z7). For testing, we got the Z7 PCI demo board. We are using u-boot and Linux kernel 2.4.25 in our system. I had a pre-conception that the Linux kernel will be able to handle the VGA console by itself without any BIOS help (or in this case U-boot). After configuring the kernel to support VGA console, the PCI video card did not give any display (probably no sync at all). AFAIK, the PCI bus is working correctly. I did test a Netgear PCI network card to verify it (and it passed). The Z7 demo card works ok on a regular Linux PC with a standard BIOS on it. 1. Does our system require a VGA BIOS (aside from U-boot) to display console (and later on to display a GUI, i.e. X Windows, Tiny X)? 2. Is it possible to configure the Kernel to do the PCI video card initialization without involving U-boot so that it will at least display a VGA console 80x25? 3. Do I actually need to write a driver for the Z7 in U-boot (similar to CT9000, SMI 710/712/810) to configure the video chip correctly before Linux takes over? 4. I still like to send U-boot console messages to the MPC8270 (SCC) serial port and just start the VGA console once Linux takes over. Is this possible? I greatly appreciate any insights about this issue. thanks in advance, Maynard

2 1

Re: [U-Boot-Users] Does u-boot relocate absolute symbols?
by Andreas Block 01 Jul '05

01 Jul '05

Jerry: I'm sorry for the inconvenience, but sent this mail to you instead of the U-Boot mailinglist. I'm not quite sure, what happened on your side. Here's the result on my side (together with the source as it ought look): --- BEGIN OF CONSOLE OUTPUT andreas@pc-linux-dev:~/arrtest> cat common.h int showwrong(void); andreas@pc-linux-dev:~/arrtest> cat common.c #include <stdio.h> extern const unsigned char test[]; int showwrong(void) { printf("test[]: 0x%08X\n", (int)test); return 0; } andreas@pc-linux-dev:~/arrtest> cat array.c #include "common.h" const unsigned char *test = (unsigned char*)0x40000; int main(void) { printf("*test: 0x%08X\n", (int)test); showwrong(); return 0; } andreas@pc-linux-dev:~/arrtest> gcc -o arrtest -I ./ ./common.c ./array.c andreas@pc-linux-dev:~/arrtest> ./arrtest *test: 0x00040000 test[]: 0x080494E4 --- END OF CONSOLE OUTPUT What buffles me is, that on your side, the *test-output isn't 0x40000, because the pointer is initialized directly in that object and used as pointer. And on the other hand, the output can't be the same: extern char test[]; ==> results in a symbol at the start address of the array. char *test; ==> is a pointer containing the start-address of the array. This means one more level of reference. Could you please show your source files as they were used for your test to us. I'm still sure, both notations are not the same, although they work the same in most cases. Regards, Andreas 30.06.2005 19:28:32, Jerry Van Baren <gerald.vanbaren(a)smiths-aerospace.com> wrote: > Rune Torgersen wrote: >> Wow.... This surprises me... >> I have alwayts thought that *test and test[] would be the same thing. >> Only solutionI can see is to change the definition in common.c to be >> *test, this will still get the address of test[] defined elsewhere. >> (See attached files) >> >>> Sure, I've tried this. This is the point, where my problemarose. >>> Attached you find twosmall files, you can easily compile under linux >>> (gcc -oarrtest -I ./ ./common.c./array.c). The file "common.c" >>> represents the code I can't(don't want to) touch."array.c" represents >>> my project dependent code. If you runarrtest it will show to you, > > With the patch in place (previously sent to the list), it works for > linux: > > vanbaren@sherwood:~/x> ll > total 32 > -rwxr----- 1 vanbaren users 200 Jun 30 13:24 array.c > -rwxr-xr-x 1 vanbaren users 8963 Jun 30 13:26 arrtest > -rwxr----- 1 vanbaren users 132 Jun 30 08:03 common.c > -rwxr----- 1 vanbaren users 121 Jun 30 08:03 common.c-original > -rw-r--r-- 1 vanbaren users 237 Jun 30 08:04 common.c.diff > -rwxr----- 1 vanbaren users 24 Jun 30 13:23 common.h > vanbaren@sherwood:~/x> gcc -o arrtest -I ./ ./common.c ./array.c > vanbaren@sherwood:~/x> ./arrtest > *test: 0x08048558 > test[]: 0x08048558 > > gvb > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > >

2 2