February 2008 - U-Boot

[U-Boot-Users] [new uImage] patchset4 - assorted patches available in u-boot-testing new-image branch
by Bartlomiej Sieka 22 Feb '08

22 Feb '08

Hello, As already hinted, code from patchset4 (assorted patches) is now available on the new-image branch of the u-boot-testing repo. You can browse the code by going to: http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-testing.git;a=shortlo… Or you can pull it locally to take a closer look, test, etc, by using: git pull \ git://www.denx.de/git/u-boot-testing.git/ new-image:u-boot-testing/new-image Comments, questions, etc are welcome. Regards, Bartlomiej

1 0

[U-Boot-Users] [PATCH 0/5 RESEND] [new uImage] patchset4 - assorted patches
by Bartlomiej Sieka 22 Feb '08

22 Feb '08

Addressed comments posted to the first version, dropped patch fixing fdt_support.c compilation with DEBUG enabled. Patches apply on top of new-image branch of the u-boot-testing, with recent master pulled. Original description: This patchset encompasses some clean-ups and fixes, and adds the new uImage #define knob (CONFIG_FIT), which is enabled by default. The patchset also adds some new uImage-specific functionality: (1) a routine to parse new-style arguments to bootm (and other commands), (2) a generic function for retrieving images. It lays foundation for the soon-to-follow: - low-level new uImage handling functions - mkimage extensions to allow generation of new format images - U-Boot support for booting new format images Code from this patchset will be soon available from the new-image branch of the u-boot-testing repository. Please review, test and provide comments. Marian Balakowicz (5): [new uImage] Fix erroneous use of image_get_magic() in fdc/usb cmds [new uImage] Rename and move print_image_hdr() routine [new uImage] Add fit_parse_conf() and fit_parse_subimage() routines [new uImage] Add gen_get_image() routine [new uImage] Pull in libfdt if CONFIG_FIT is enabled Regards, Bartlomiej

2 7

[U-Boot-Users] AT91SAM9260EK -> DaviCom PHY -> How to disable Autonegotiation ??
by Manuel Sahm 22 Feb '08

22 Feb '08

Hello, how could I disable the autonegotiation process in uboot ? my PC Lan Card dosn?t support this feature !!! -- Freundliche Grüße / Best regards Manuel Sahm

1 0

Re: [U-Boot-Users] Taishan linker problem.
by k b 22 Feb '08

22 Feb '08

> > Please keep the mailing list on Cc: !!! > Sorry that was a mistake. In regards to the problem i'm seeing i was looking through the changelog of 1.1.5 and the mentions fixing this problem. here's the link that shows the changelog http://svn.digium.com/view/aadk-old/u-boot/upstream/r614/u-boot_1.1.6/CHANG… I understand that 1.2.0 is old but considering that this was fixed in 1.1.5, do you think going to 1.3.2-rc1 would change this ? Again as i said if you could give me some input as to what the error means i could try something. best regards, Kunal _________________________________________________________________ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

1 0

[U-Boot-Users] Temperature sensor on Sequoia board
by Larry Johnson 21 Feb '08

21 Feb '08

Hi Stefan and group, When I was checking the LM75/AD7414 driver using my Sequoia board, I found that the AD7414 on the Sequoia does not appear to update its temperature as its documentation describes. I had to reset U-Boot to get the temperature reading to change. Also, every since I have had that board, the first temperature reading reported by U-Boot after applying power has always been incorrect. I didn't find anything in the AD7414 documentation that would explain this. Has anyone seen this behavior on other Sequoia boards? Best regards, Larry

1 0

[U-Boot-Users] Make love to her longer and harder with this.
by mujaahid Pielich 21 Feb '08

21 Feb '08

Hot sultry babes waiting for you here.

1 0

[U-Boot-Users] ramdisk problem (once again?)
by Miguel Angel Alvarez 21 Feb '08

21 Feb '08

Hi I am experiencing problems using a ramdisk with Das u-boot, and although I have been reading the previous questions and answers in the mailing list I cannot solve the question. The problem: I can start a Linux kernel and its filesystem from flash (linux image made using mkimage, and filesystem in cramfs format). However, if I try to boot them from flash (this time both images have been constructed using mkimage), the kernel starts, but a "No filesystem could mount root, tried: cramfs romfs" appears. Upload of kernel: tftp 0x260000 linux.uboot Upload of fs: tftp 0x3a0000 root.uboot Environment: => printenv bootcmd=run bootflash bootdelay=3 baudrate=115200 eth1addr=00:02:b3:02:02:02 kernel_addr=50060000 ramdisk_addr=501A0000 bootflash=bootm $(kernel_addr) stdin=serial stdout=serial stderr=serial ethact=i82559#0 ethaddr=00:11:22:33:44:55 tftpdstp=10069 bootargs=console=ttyS0,115200 root=/dev/ram0 rw irqpoll mtdparts=physmap-flash.0:256k(boot),128k(conf),1280k(linux),-(root) mem=128MB filesize=f4040 fileaddr=3A0000 netmask=255.255.0.0 ipaddr=128.127.165.133 serverip=128.127.50.94 As you can see, I do not use initrd param because I suppose it is directly passed to the kernel. Whole log: ### Configuring the network setenv ethaddr 00:11:22:33:44:55 => setenv ipaddr 128.127.165.133 => setenv serverip 128.127.50.94 => setenv netmask 255.255.0.0 => setenv tftpdstp 10069 => setenv bootargs console=ttyS0,115200 root=/dev/ram0 rw irqpoll mtdparts=physmap-flash.0:256k(boot),128k(conf),1280k(linux),-(root) mem=128MB => ### Uploading kernel tftp 0x260000 linux.uboot Using i82559#0 device TFTP from server 128.127.50.94; our IP address is 128.127.165.133 Filename 'linux.uboot'. Transferred 0 KB of 1111 KB (0 %)60000 Transferred 185 KB of 1111 KB (16 %)############################# ################################################################# #################################################################ERROR: Timeout waiting for ack (errno: 11 n: -1) ERROR: Ack(s) lost. Resending: 1950 ERROR: Ack(s) lost. Resending complete. Transferred 1111 KB of 1111 KB (100 %)############# # done Bytes transferred = 1138480 (115f30 hex) => ### Uploading file system tftp 0x3a0000 root.uboot Using i82559#0 device TFTP from server 128.127.50.94; our IP address is 128.127.165.133 Filename 'root.uboot'. Load address: 0x3a0000 Loading: ################################################################# Transferred 465 KB of 976 KB (47 %)###################################### Transferred 976 KB of 976 KB (100 %)###################################### # done Bytes transferred = 999488 (f4040 hex) => ### Boot from ram bootm 0x260000 0x3a0000 ## Booting image at 00260000 ... Image Name: linux-2.6.22.15 Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 1138416 Bytes = 1.1 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading Ramdisk Image at 003a0000 ... Image Name: root Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 999424 Bytes = 976 kB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Starting kernel ... Linux version 2.6.22.15-uSysCom (mac@mac2) (gcc version 4.1.2) #10 PREEMPT Mon Feb 11 20:15:32 CET 2008 CPU: XScale-IXP46x Family [69054202] revision 2 (ARMv5TE), cr=000039ff Machine: Intel IXDP465 Development Platform Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT undefined 5 cache CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Built 1 zonelists. Total pages: 32512 Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw irqpoll mtdparts=physmap-flash.0:256k(boot),128k(conf),1280k(linux),-(root) mem=128MB Misrouted IRQ fixup and polling support enabled This may significantly impact system performance PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 127232KB available (2204K code, 226K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 IXP4xx: Using 32MiB expansion bus window size usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Time: OSTS clocksource has been installed. Switched to high resolution mode on CPU 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NetWinder Floating Point Emulator V0.97 (double precision) io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale RAMDISK driver initialized: 4 RAM disks of 8192K size 1024 blocksize loop: module loaded tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk(a)qualcomm.com> physmap platform flash device: 02000000 at 50000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled 4 cmdlinepart partitions found on MTD device physmap-flash.0 Creating 4 MTD partitions on "physmap-flash.0": 0x00000000-0x00040000 : "boot" 0x00040000-0x00060000 : "conf" 0x00060000-0x001a0000 : "linux" 0x001a0000-0x02000000 : "root" i2c /dev entries driver Driver for 1-wire Dallas network protocol. device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel(a)redhat.com nf_conntrack version 0.5.0 (1024 buckets, 8192 max) IPv4 over IPv4 tunneling driver GRE over IPv4 tunneling driver ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered NET: Registered protocol family 33 802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com> All bugs added by David S. Miller <davem(a)redhat.com> SCTP: Hash tables configured (established 4096 bind 8192) XScale DSP coprocessor detected. List of all partitions: 1f00 256 mtdblock0 (driver?) 1f01 128 mtdblock1 (driver?) 1f02 1280 mtdblock2 (driver?) 1f03 31104 mtdblock3 (driver?) No filesystem could mount root, tried: cramfs romfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) I am not quite sure about the -a and -e parameters for the mkimage (I have tried different ones for the ramdisk... the kernel seems to be correct with 0x8000). The RAM of my system begins on 0x0 and then is moved into 0x200000. Any clues? Thanks Miguel Ángel This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

5 9

[U-Boot-Users] Change your tiny tool into a POWER DRILL .
by Kate ancheta 21 Feb '08

21 Feb '08

Women want to be penetrated deeply and tightly, and you simply can't do that with small equipment.

1 0

[U-Boot-Users] how to time/profile u-boot
by Lakshminarasimhan Sampath 21 Feb '08

21 Feb '08

Hello, I am very new to u-boot, and my first task here is, I have to time u-boot to see how long it takes and which functions we can modify to make it faster, if possible and necessary. But, I am not sure if there is any way to profile u-boot. Can someone please help me in this? How can I get to see how long each function has taken? Thanks, VS -- ------------------------------------------------------------- "nesarai kaanavidaththe nenjaarave pugazh"

1 0

[U-Boot-Users] watchdog usage in U-Boot
by w.wegner＠astro-kom.de 21 Feb '08

21 Feb '08

Hi, maybe this is again a stupid question, but I did not yet figure out about it myself, so maybe somebody could give me some pointers and/or correct my assumptions. I want to use the watchdog in my MCF5373L board (which is supported by U-Boot using the MCF532x code). I find watchdog_init and so on but I did not see any of these being called anywhere from within U-Boot. However, when enabling the watchdog with CONFIG_WATCHDOG, the timer already starts and will expire if any U-Boot internal task takes too long. >From other posts I found some things that I would like to state as assumptions, please correct me if any of these is wrong - watchdog is not initialized by default, has to be done by board-specific code - watchdog servicing (reset the counter) is also not done by default - has to be done by board-specific code - I saw a patch by Wolfgang that splits udelay, but did not see how the watchdog_reset is handled by this? Where is this done? My problem with this is: - enabling watchdog with CONFIG_WATCHDOG will not disable the (normally enabled) watchdog during startup and thus it will time out with time-consuming tasks (like bootdelay or loading a large FPGA) - I have no defined "watchdog service" before control is handed over to the linux kernel, so even when the linux kernel would have support for the correct watchdog (which I still have to implement), the timeout is never well defined at this point. I can implement watchdog_init() in my board-specific startup code and call watchdog_reset from time to time during my board-specific FPGA loader, but first this seems not to be a very elegant way and second this does not solve the problem of bootdelay and handing over control to the linux kernel. I would be happy if anybody could give some hints despite this long text... Regards, Wolfgang

2 2