Re: [U-Boot] U-Boot TFTP protection
Hi Stefan, On 15 June 2018 at 00:44, Stefan Johansson wrote: > > Hello, > We have been looking at protecting U-Boot from (malicious) TFTP overwrites. > We want to do this after our ARMv7 U-Boot has relocated. > > The memory map looks like this (I hope): > > --- Top of DRAM > | U-Boot (Protected) > | -- U_Boot_start > | Heap (Protected) > | -- Start_Heap = U_Boot_start - Heap_Size > | Stack (Protected) > | -- Start_Stack = Start_Heap - Stack_Size > | Buffers (Protected) > | -- ??? > | Free DRAM (Not Protected) > --- Start of DRAM > > I seem to get lost in the code trying to find possible buffers, can you > please give a hint how I can find the address "???" Well gd->start_addr_sp is the stop of the stack. The size of the stack is not necessarily fixed and will grow downwards from there. But I suppose you could set a particular size and protect from start of DRAM to to the assumed bottom of the stack area. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot TFTP protection
Hi Stefan, > Hello, > We have been looking at protecting U-Boot from (malicious) TFTP > overwrites. We want to do this after our ARMv7 U-Boot has relocated. > > The memory map looks like this (I hope): > > --- Top of DRAM > | U-Boot (Protected) > | -- U_Boot_start > | Heap (Protected) > | -- Start_Heap = U_Boot_start - Heap_Size > | Stack (Protected) > | -- Start_Stack = Start_Heap - Stack_Size > | Buffers (Protected) > | -- ??? > | Free DRAM (Not Protected) > --- Start of DRAM > > I seem to get lost in the code trying to find possible buffers, can > you please give a hint how I can find the address "???" By default the tftp writes its data to the address pointed by the "loadaddr" env variable. printenv loadaddr > > Best Regards, > Stefan > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgp7YYkFCGuxY.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot TFTP protection
Hello, We have been looking at protecting U-Boot from (malicious) TFTP overwrites. We want to do this after our ARMv7 U-Boot has relocated. The memory map looks like this (I hope): --- Top of DRAM | U-Boot (Protected) | -- U_Boot_start | Heap (Protected) | -- Start_Heap = U_Boot_start - Heap_Size | Stack (Protected) | -- Start_Stack = Start_Heap - Stack_Size | Buffers (Protected) | -- ??? | Free DRAM (Not Protected) --- Start of DRAM I seem to get lost in the code trying to find possible buffers, can you please give a hint how I can find the address "???" Best Regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hello, Joe Recently I have repeated my tests. U-Boot logs along with pcap dump could be found here: https://mega.co.nz/#!g4UnVaDL!K6ej1OQXg5VE6pU5cmFoELkeqasIDXH1OZbDwdLiXSU I may be wrong, but after careful examination of these dumps (and older ones), I came to the following conclusion: Somehow lost packets coincide with --- NetLoop timeout handler set and --- NetLoop timeout. Which is supported by these facts: a) both server and u-boot tftp timeouts are equal to 5 sec; b) whenever I define #define TIMEOUT 8000UL, even if U-Boot fails to catch the first packet, it catches the second one and does not reset it's timer (which seems to generate another one ACK for the last received block upon reset); c) similarly if I set tftptimeout 1000, U-Boot still catches the second packet if it could not catch the first one. Moreover after yet another examination of windows server session dump I find, this is exactly what happens with windows server, which ignores u-boot's request for 5 second timeout and resends blocks after 1 second, which are perfectly captured by U-Boot; d) all those packets within 5 seconds' timeout got caught by U-Boot. Please correct me if I'm wrong. And if I'm not - is there anything to mitigate this, other than set tftptimeout 1000 and put switch inbetween? Referring some...@ti.com to this thread maybe? BTW: putting switch inbetween makes it easier for U-Boot to catch up with tftp server. Compare: U-Boot dhcp BOOTP broadcast 1 DHCP client bound to address 192.168.100.88 (81 ms) Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: ##T T ##T ## Abort U-Boot dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.100.88 (1074 ms) Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: #T #T T ##T #T T #T #T #T ##T #T ### Abort U-Boot dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 DHCP client bound to address 192.168.100.88 (4817 ms) Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # # T ##T ### # # #T 34.2 KiB/s done Bytes transferred = 2225360 (21f4d0 hex) U-Boot dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.100.88 (1079 ms) Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: T ###T ## T ###T T ### # # T # # #T 32.2 KiB/s done Bytes transferred = 2225360 (21f4d0 hex) Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hello, Joe Can you provide more exact details on the servers you are trying including versions? Perhaps also provide pcap files (not text dumps) so the exact packet contents can be observed? Recently I've done some tests, hope you find them interesting. Server in question: Linux sterver 3.2.0-4-686-pae #1 SMP Debian 3.2.65-1+deb7u1 i686 GNU/Linux r8169 :08:04.0: eth1: RTL8169sc/8110sc at 0xf827e000, 90:e6:ba:07:3e:a5, XID 1800 IRQ 19 ii tftpd 0.17-18 i386 Trivial file transfer protocol server I have mirrored 2 ports at the switch. Here's what I have found: 1. tftp block ack packets have some extra bytes. They are mage octet tim. Suppose that's because buffer reuse in u-boot after uImage octet timeout 5, although I'm not so sure. 2. u-boot never generates wrong block acks if #define TIMEOUT 8000UL. Obviously 8 seconds is enough for tftp server to resend the block, so with this define, it is not timing out and keeps downloading till the end. Ofcourse it just masks the real problem, nothing more. 3. at the times of server resending block it is u-boot who lost the packet. I believe that if the packet was delivered to mirrored port, it must have been delivered to u-boot. But logging at u-boot shows no evidence of packet reception, however packets following missed one are registered. 4. the only condition at which u-boot didn't loose packets and downloaded uImage without timeouts was when I made it log everything regarding network. this gave enormous output to console, but no tftp packets lost. Even though I tested it twice it could be a coincidence. Also I tried disabling caches. Rebuilding with CONFIG_SYS_ICACHE_OFF and CONFIG_SYS_DCACHE_OFF was no difference at all. At least for tftp download. I was about to provide you with pcap files from mirror port and corresponding u-boot console log, but sadly seems that I have deleted u-boot log by mistake :( I think I have to repeat the whole thing before I can provide you with them both. Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
On Fri, Feb 20, 2015 at 10:51 AM, PF4Public pf4pub...@mail.ru wrote: Hello, Nikolay Now I see, what you mean. From every dump the requests made by U-Boot are the same. They're as follows: 00:00:00.000310 IP (tos 0x0, ttl 255, id 11267, offset 0, flags [DF], proto UDP (17), length 66) 192.168.100.88.3821 192.168.100.254.69: 38 RRQ uImage octet timeout 5 blksize 1468 However the answers from servers are different. Linux host answers with 516 byte packets for example: 00:00:00.004169 IP (tos 0x0, ttl 64, id 29290, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1 Whereas Windows host answers conforming to requested block size somewhat: 00:00:00.000136 IP (tos 0x0, ttl 128, id 20143, offset 0, flags [none], proto UDP (17), length 1500) 192.168.100.86.63959 192.168.100.88.3811: 1472 DATA block 1 Also those configs, which contain #define CONFIG_TFTP_BLOCKSIZE 4096, are from completely different boards. As well as neither did I nor it was by default defined for mine board. So I believe that there must be something different with my set up. I have not yet tried debugging network at U-Boot side, but it is the last thing, that left to check. I actually just tested this on sandbox against atftpd server 0.7 in Ubuntu Linux. Even with IP Fragmentation and 4k block size, u-boot acked every packet correctly. Can you provide more exact details on the servers you are trying including versions? Perhaps also provide pcap files (not text dumps) so the exact packet contents can be observed? -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hi PF4Public, On 02/20/2015 04:43 PM, PF4Public wrote: When working with large TFTP packets (probably 4096 bytes, as set in your board config file), U-Boot TFTP code sends wrong acknowledges for the TFTP packets. But what is clear from traffic dumps is that a packet size never exceeds 516 when downloading from Linux machine's tftpd. Am I missing something here? Hmm. Please check your boards' initial TFTP request packet, and especially the option blksize field. My understanding is that it should be the same as the size of all incoming TFTP data blocks, and when they're not equal sized, U-Boot TFTP code has issues to reassemble the fragments. That's why I recommended to use the default max TFTP blocksize which is 1468 bytes and fits nicely in a single ethernet frame. This is based on my own observations some time ago when debugged somewhat similar issues with U-Boot running on ARM, and trying to boot from OpenBSD TFTP server. Reduce your TFTP blksize, by commenting CONFIG_TFTPBLOCKSIZE in your board config. The default value is 1468, which should work fine. I have tried reducing tftpblocksize with editenv command of U-Boot, that ensured reduced blocksizes, which was clearly visible in tcpdump, but sadly it didn't change a thing. Btw I cannot find CONFIG_TFTPBLOCKSIZE in the whole source tree of U-Boot: grep -r CONFIG_TFTPBLOCKSIZE . and grep -r TFTPBLOCKSIZE . gave no output. Sorry for the confusion, it's CONFIG_TFTP_BLOCKSIZE. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hello, Nikolay Now I see, what you mean. From every dump the requests made by U-Boot are the same. They're as follows: 00:00:00.000310 IP (tos 0x0, ttl 255, id 11267, offset 0, flags [DF], proto UDP (17), length 66) 192.168.100.88.3821 192.168.100.254.69: 38 RRQ uImage octet timeout 5 blksize 1468 However the answers from servers are different. Linux host answers with 516 byte packets for example: 00:00:00.004169 IP (tos 0x0, ttl 64, id 29290, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1 Whereas Windows host answers conforming to requested block size somewhat: 00:00:00.000136 IP (tos 0x0, ttl 128, id 20143, offset 0, flags [none], proto UDP (17), length 1500) 192.168.100.86.63959 192.168.100.88.3811: 1472 DATA block 1 Also those configs, which contain #define CONFIG_TFTP_BLOCKSIZE 4096, are from completely different boards. As well as neither did I nor it was by default defined for mine board. So I believe that there must be something different with my set up. I have not yet tried debugging network at U-Boot side, but it is the last thing, that left to check. But anyway thank you for your insight for large packets and U-Boot. Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hi, Here's what I think happens: When working with large TFTP packets (probably 4096 bytes, as set in your board config file), U-Boot TFTP code sends wrong acknowledges for the TFTP packets. If the TFTP server implementation is too strict (the OpenBSD server is a good example), the transfer will inevitably fail very soon after start. Here's an example: 1. TFTP server sends block 0 2. Board acknowledges block 0 3. TFTP server sends block 1 4. Board acknowledges block 0 At this point you can see either proper or very obscure error messages in the TFTP server logs, so trust only to network dumps for diagnostics. What can you do to resolve your issue: 1. Fix the bug in U-Boot tftp networking code and submit a patch. 2. Reduce your TFTP blksize, by commenting CONFIG_TFTPBLOCKSIZE in your board config. The default value is 1468, which should work fine. U-Boot behaves nicer with smaller packets. Hope this helps. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Are you saying that it is completely consistent that when TFTPing from a specific TFTP server to u-boot you always get these time-outs, but with a different one you never get them? Exactly. Even when I try to download uImage from kvm host machine, I still got timeouts. But should I try to download from kvm guest, which obviously uses the same switch port as does host, I got fast download. A little slower, but still without timeouts, tftp gets uImage from MS Windows 7 host, which runs http://tftpd32.jounin.net/ .That was the first I could google up for Windows. Have you compared the traffic on the wire? Careful examination of dumps leads me to the following conclusions: 1. Download session with timeouts had a lot of retransmissions. Having those dumps made on server side, I'm not certain if U-Boot really received lost packets, but what is clear is that tftpd sends some packets twice before receiving acknowledgement packet from U-Boot. 2. Even though Windows server uses block sizes 1500, still those packets are perfectly delivered to U-Boot. 3. Sometimes something really weird happens, like this: 00:00:00.61 IP (tos 0x0, ttl 64, id 34608, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 423 00:00:00.000417 IP (tos 0x0, ttl 255, id 11691, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 423 00:00:00.56 IP (tos 0x0, ttl 64, id 34609, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 424 00:00:05.000165 IP (tos 0x0, ttl 255, id 11692, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 423 00:00:00.14 IP (tos 0x0, ttl 64, id 34720, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 424 00:00:00.15 IP (tos 0x0, ttl 64, id 34721, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 424 00:00:00.000521 IP (tos 0x0, ttl 255, id 11693, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 424 That is tftpd sends block 423 and receives acknowledgement. Then it sends block 424, but the reply was delayed for 5 seconds and was in fact for block 423 again. This happened quite often with timing variations: 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 526 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 527 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 527 ... 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1558 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1559 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 192.168.100.254.56334: 4 ACK block 1559 Try turning on debug traces in the network stack and compare what it sees to what's on the wire. I'll give it a try, thanks. Is #define DEBUG_NET_PKT 0 related here, which I found in include/net.h ? Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your board that you could disable to eliminate the driver's tolerance of a cache? You mean CONFIG_SYS_ICACHE_OFF and CONFIG_SYS_DCACHE_OFF. I'll try them. I've googled something like dcache off command, but it didn't work for me in U-Boot command line, so suppose I should disable them via defines. Am I right? Simply that the packet that the network stack expects has not be received at that level. They could be lost in a number of places. But how come they are lost so selectively? I mean that somehow packets from Windows and other Linux hosts got delivered just fine. Best regards. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
On Fri, Feb 13, 2015 at 8:05 PM, PF4Public pf4pub...@mail.ru wrote: Hi all I'm asking for your help to figure out what interferes with u-boot's tftp in my setup. I have a custom board with TI OMAP SoC. I'm trying to download uImage from linux machine via tftp. It fails with timeouts (most of the tries timeout limit exceeds) on several, but succeeds on others. However any other combination not involving u-boot is flawless. Even when the board in question has booted kernel. Comparing network settings (incl. sysctl) gave no significant difference between serving machines, which run Linux. Are you saying that it is completely consistent that when TFTPing from a specific TFTP server to u-boot you always get these time-outs, but with a different one you never get them? Have you compared the traffic on the wire? Try turning on debug traces in the network stack and compare what it sees to what's on the wire. Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your board that you could disable to eliminate the driver's tolerance of a cache? Following tests were taken: u-boot - i686-pae Linux u-boot - i686-pae Linux kvm guest u-boot - x86_64 windows 7 Results are as follows: 1. u-boot - i686-pae Linux Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: T ###T ##T ###T T ## ##T ### ###T ## T # # T # ## 11.7 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/hBBwe9bL 2. u-boot - i686-pae Linux kvm guest Using DaVinci-EMAC device TFTP from server 192.168.100.112; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # # # # # # ## 795.9 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/ZXYdpmSe 3. u-boot - x86_64 windows 7 Using DaVinci-EMAC device TFTP from server 192.168.100.86; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # ### 173.8 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/UWFEZjTz At this point I have no idea, what could cause timeouts for u-boot and I have no more clues on how to solve this. Any help greatly appreciated. Simply that the packet that the network stack expects has not be received at that level. They could be lost in a number of places. Thanks in advance Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot tftp problem
Hi all I'm asking for your help to figure out what interferes with u-boot's tftp in my setup. I have a custom board with TI OMAP SoC. I'm trying to download uImage from linux machine via tftp. It fails with timeouts (most of the tries timeout limit exceeds) on several, but succeeds on others. However any other combination not involving u-boot is flawless. Even when the board in question has booted kernel. Comparing network settings (incl. sysctl) gave no significant difference between serving machines, which run Linux. Following tests were taken: u-boot - i686-pae Linux u-boot - i686-pae Linux kvm guest u-boot - x86_64 windows 7 Results are as follows: 1. u-boot - i686-pae Linux Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: T ###T ##T ###T T ## ##T ### ###T ## T # # T # ## 11.7 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/hBBwe9bL 2. u-boot - i686-pae Linux kvm guest Using DaVinci-EMAC device TFTP from server 192.168.100.112; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # # # # # # ## 795.9 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/ZXYdpmSe 3. u-boot - x86_64 windows 7 Using DaVinci-EMAC device TFTP from server 192.168.100.86; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # ### 173.8 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/UWFEZjTz At this point I have no idea, what could cause timeouts for u-boot and I have no more clues on how to solve this. Any help greatly appreciated. Thanks in advance Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hello all, I really appreciate all of your replies and sorry for not being responsive for sometime. But I am glad to say that I was able to flash new u-boot along with fman ucode and rcw. I am using p4080DS dev board from freescale and the rcw is important in terms of which ports to be enabled upon boot. I ran into all of these problems because the ltib version I was using was not compatible with my version of the board. Wish I knew this earlier but there was no way for me to find this out. Neways all is up and running and thanks once again for providing all the help. Sincerely,Simran Date: Thu, 21 Jul 2011 10:24:07 + Subject: Re: [U-Boot] U-BOOT TFTP From: vickylinu...@gmail.com To: simrangill...@hotmail.com CC: u-boot@lists.denx.de Hello simran The things u have to do is check your network connectivity between board and target .If it is not working after that, make a clean u-boot compilation again with basic configuration(no confusing) of your board header file and port again. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hi simran, you should really provide us with more data to give us even a remote chance of helping you. What board do you use, what CPU is it, what U-Boot version do you use? Are you doing a custom U-Boot port or simply use a well-supported U-Boot configuration from mainline? Hello, This is the ouput when I do tftp or try the ping with the environment set accordingly. Could it possibly be one of the configuration files such as the RCW (reset configuration word) but I cannot change this file withno tftp connection.Any help would be great. Thank you. To be honest, I do not understand what a RCW has got to do with a tftp transfer. = ping 192.168.1.1 ping failed; host 192.168.1.1 is not alive = ping 192.168.1.129 ping failed; host 192.168.1.129 is not alive = tftp 100 /tftpboot/uImage = tftp 0x100 /tftpboot/uImage = = printenv ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr bootdelay=10 baudrate=115200 loads_echo= rootpath=/opt/nfsroot loadaddr=100 netdev=eth0 uboot=u-boot.bin tftpflash=tftpboot $loadaddr $uboot; protect off 0xeff8 +$filesize; erase 0xeff8 +$filesize; cp.b $loadaddr 0xeff8 $filesize; protect on 0xeff8 +$filesize; cmp.b $loadaddr 0xeff8 $filesize consoledev=ttyS0 ramdiskaddr=200 fdtaddr=c0 fman_ucode=0xEF00 eth1addr=00:04:9F:02:01:FD eth2addr=00:04:9F:02:02:FD eth3addr=00:04:9F:02:03:FD eth4addr=00:04:9F:02:04:FD eth5addr=00:04:9F:02:05:FD eth6addr=00:04:9F:02:06:FD eth7addr=00:04:9F:02:07:FD eth8addr=00:04:9F:02:08:FD eth9addr=00:04:9F:02:09:FD bootfile=uImage ramdiskfile=rootfs.ext2.gz.uboot fdtfile=p4080ds.dtb bdev=sda3 bank4=mw.b 0xffdf002c 0x40; mw.b 0xffdf002d 70; mw.b 0xffdf0010 0; mw.b 0xffdf0010 1 gatewayip=192.168.1.1 bootcmd=bootm e802 e930 e880 ipaddr=192.168.1.145 serverip=192.168.1.129 bootargs=root=/dev/mtdblock0 rw console=ttyS0,115200 ethaddr=00:C0:F7:02:01:FD stdin=serial stdout=serial stderr=serial ethact=FM1@DTSEC1 Environment size: 1500/8188 bytes Where do all those empty lines in the log come from? Are you sure that the setting for ethact is correct? Do you really have 8 network devices but only 4 mac addresses assigned to them? I.e. usually we have ethaddr, eth1addr, etc. for the network interfaces - I've never seen such a combinmation as in your logs. Do you have the variable netmask setup correctly? In short, it seems like there is a lot of confusion in your setup. Does U-Boot work for you at all or is the network failure only one of the problems? Cheers Detlev -- Nothing under heaven is softer or more yielding than water; but when it attacks things hard and resistant there is not one of them that can prevail. For they can find no way of altering it. That the yielding conquers the resistant and the soft conquers the hard is a fact known by all men, yet utilised by none. -- Tao Te Ching -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hello simran The things u have to do is check your network connectivity between board and target .If it is not working after that, make a clean u-boot compilation again with basic configuration(no confusing) of your board header file and port again. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hello, This is the ouput when I do tftp or try the ping with the environment set accordingly. Could it possibly be one of the configuration files such as the RCW (reset configuration word) but I cannot change this file withno tftp connection.Any help would be great. Thank you. = ping 192.168.1.1 ping failed; host 192.168.1.1 is not alive = ping 192.168.1.129 ping failed; host 192.168.1.129 is not alive = tftp 100 /tftpboot/uImage = tftp 0x100 /tftpboot/uImage = = printenv ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr bootdelay=10 baudrate=115200 loads_echo= rootpath=/opt/nfsroot loadaddr=100 netdev=eth0 uboot=u-boot.bin tftpflash=tftpboot $loadaddr $uboot; protect off 0xeff8 +$filesize; erase 0xeff8 +$filesize; cp.b $loadaddr 0xeff8 $filesize; protect on 0xeff8 +$filesize; cmp.b $loadaddr 0xeff8 $filesize consoledev=ttyS0 ramdiskaddr=200 fdtaddr=c0 fman_ucode=0xEF00 eth1addr=00:04:9F:02:01:FD eth2addr=00:04:9F:02:02:FD eth3addr=00:04:9F:02:03:FD eth4addr=00:04:9F:02:04:FD eth5addr=00:04:9F:02:05:FD eth6addr=00:04:9F:02:06:FD eth7addr=00:04:9F:02:07:FD eth8addr=00:04:9F:02:08:FD eth9addr=00:04:9F:02:09:FD bootfile=uImage ramdiskfile=rootfs.ext2.gz.uboot fdtfile=p4080ds.dtb bdev=sda3 bank4=mw.b 0xffdf002c 0x40; mw.b 0xffdf002d 70; mw.b 0xffdf0010 0; mw.b 0xffdf0010 1 gatewayip=192.168.1.1 bootcmd=bootm e802 e930 e880 ipaddr=192.168.1.145 serverip=192.168.1.129 bootargs=root=/dev/mtdblock0 rw console=ttyS0,115200 ethaddr=00:C0:F7:02:01:FD stdin=serial stdout=serial stderr=serial ethact=FM1@DTSEC1 Environment size: 1500/8188 bytes = boot From: simrangill...@hotmail.com To: vickylinu...@gmail.com Date: Sun, 17 Jul 2011 18:40:55 -0700 CC: u-boot@lists.denx.de Subject: Re: [U-Boot] U-BOOT TFTP Hello,Nothing happens after I run the tftp command. It just returns a new u-boot prompt with no warnings at all. Date: Sat, 16 Jul 2011 06:01:27 + Subject: Re: [U-Boot] U-BOOT TFTP From: vickylinu...@gmail.com To: simrangill...@hotmail.com CC: u-boot@lists.denx.de Hi Can u give a clear log about uboot version and what u getting after executing tftp 100 /tftpboot/uImage. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hello,Nothing happens after I run the tftp command. It just returns a new u-boot prompt with no warnings at all.Is there a tftp variable in u-boot that has to be set inorder for the tftp to work. From: simrangill...@hotmail.com To: vickylinu...@gmail.com Date: Sun, 17 Jul 2011 18:40:55 -0700 CC: u-boot@lists.denx.de Subject: Re: [U-Boot] U-BOOT TFTP Hello,Nothing happens after I run the tftp command. It just returns a new u-boot prompt with no warnings at all. Date: Sat, 16 Jul 2011 06:01:27 + Subject: Re: [U-Boot] U-BOOT TFTP From: vickylinu...@gmail.com To: simrangill...@hotmail.com CC: u-boot@lists.denx.de Hi Can u give a clear log about uboot version and what u getting after executing tftp 100 /tftpboot/uImage. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hello,Nothing happens after I run the tftp command. It just returns a new u-boot prompt with no warnings at all. Date: Sat, 16 Jul 2011 06:01:27 + Subject: Re: [U-Boot] U-BOOT TFTP From: vickylinu...@gmail.com To: simrangill...@hotmail.com CC: u-boot@lists.denx.de Hi Can u give a clear log about uboot version and what u getting after executing tftp 100 /tftpboot/uImage. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
Hi Can u give a clear log about uboot version and what u getting after executing tftp 100 /tftpboot/uImage. Regards Vignesh Rajendran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT TFTP
sorry about my wrong post ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-BOOT TFTP
Hello,I am running Linux 2.6.34.6 on p4080ds board. I am trying to get the interfaces running on the kernel but it does not seem to be working. So far I am able to set up the ipaddress etc for the interface fm1-gb1 but still cannot ping the outside world. I edited the file /etc/rc.d/rc.conf with no luck. My configuration is as follows: address@hidden rc.d]# vi rc.conf export HOSTNAME=p4080 export NTP_SERVER= export MODLIST= export RAMDIRS= export TMPFS=tmpfs export TMPFS_SIZE=512k export READONLY_FS= export INETD_ARGS= export BOA_ARGS=-c /etc export SMBD_ARGS= export NMBD_ARGS= export DHCP_ARG= export DEPLOYMENT_STYLE=RAMDISK export SYSCFG_DHCPC_CMD=udhcpc -b -i export DROPBEAR_ARGS= export SYSCFG_IFACE0=y export INTERFACE0=fm1-gb1 export IPADDR0=192.168.1.145' export NETMASK0=255.255.255.0 export BROADCAST0=192.168.1.255 export GATEWAY0=192.168.1.1 After restarting the rcS script:: address@hidden rc.d]# sh /etc/rc.d/rcS restart network Running sysctl Setting up networking on loopback device: SIOCADDRT: File exists Setting up networking on fm1-gb1: Adding static route for default gateway to 192.168.1.1: /etc/rc.d/init.d/network: line 90: cannot create tmp/hosts: nonexistent directory mv: cannot rename '/tmp/hosts': No such file or directory address@hidden rc.d]# ifconfig fm1-gb1 Link encap:Ethernet HWaddr 00:04:9F:02:01:FD inet addr:192.168.1.145 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:238 (238.0 b) Memory:fe4e2000-fe4e2fff loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) address@hidden rc.d]# Thank you in advance for any help. Sorry if this is easy, I am a little new to this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-BOOT TFTP
Sorry about my last post. I am new and need some help. Hello,I am developing on freescale P4080DS BOARD. I am trying to put new kernel image onto the board but need a tftp connection. When I type tftp 100 /tftpboot/uImage nothing happens and the new prompt appears. I was able to tftp before and upgrade but seems like one of the changes has broken it. I have set the target and host ip address accordingly. Below is the printenv on bank 0. Any help would be much appreciated. Thank you. = printenv ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr bootdelay=10 baudrate=115200 loads_echo= rootpath=/opt/nfsroot loadaddr=100 netdev=eth0 uboot=u-boot.bin tftpflash=tftpboot $loadaddr $uboot; protect off 0xeff8 +$filesize; erase 0xeff8 +$filesize; cp.b $loadaddr 0xeff8 $filesize; protect on 0xeff8 +$filesize; cmp.b $loadaddr 0xeff8 $filesize consoledev=ttyS0 ramdiskaddr=200 fdtaddr=c0 fman_ucode=0xEF00 eth1addr=00:04:9F:02:01:FD eth2addr=00:04:9F:02:02:FD eth3addr=00:04:9F:02:03:FD eth4addr=00:04:9F:02:04:FD eth5addr=00:04:9F:02:05:FD eth6addr=00:04:9F:02:06:FD eth7addr=00:04:9F:02:07:FD eth8addr=00:04:9F:02:08:FD eth9addr=00:04:9F:02:09:FD bootfile=uImage ramdiskfile=rootfs.ext2.gz.uboot fdtfile=p4080ds.dtb bdev=sda3 bank4=mw.b 0xffdf002c 0x40; mw.b 0xffdf002d 70; mw.b 0xffdf0010 0; mw.b 0xffdf0010 1 host=192.168.1.129 server=192.168.1.129 address@hidden serverip=192.168.1.129 gatewayip=192.168.1.1 ipaddr=192.168.1.145 netmask=255.255.255.0 broadcast=192.168.1.255 gateway=192.168.1.1 nameserverip=192.168.1.1 ethaddr=00:C0:F7:02:01:FD bootcmd=bootm e802 e930 e880 bootargs=root=/dev/nfs rw console=ttyS0,115200 stdin=serial stdout=serial stderr=serial Environment size: 1620/8188 bytes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
