Re: [U-Boot] [PATCH] net/dns.c: Fix endian conversion for big-endian in dns command
On Sun 16 Oct 2011 05:59, Bernhard Kaindl pondered:
From: Bernhard Kaindl bernhard.kai...@thalesgroup.com
net/dns.c used endian conversion macros wrongly (shorts in reply
were put swapped into CPU, and then ntohs() was used to swap it
back, which broke on big-endian).
Fix this by using the correct linux conversion macro for reading
a unaligned short in network byte order: get_unaligned_be16()
Thanks to Mike Frysinger pointing at the best macro to use.
Tested on big and little endian qemu boards (mips and versatile)
This also tweaks some error messages and comments, which isn't captured in the
change log?
Otherwise, Ack from me.
Signed-off-by: Bernhard Kaindl bernhard.kai...@thalesgroup.com
Cc: Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
Cc: Robin Getz rg...@blackfin.uclinux.org
---
net/dns.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/net/dns.c b/net/dns.c
index b51d1bd..7a3f1f9 100644
--- a/net/dns.c
+++ b/net/dns.c
@@ -25,6 +25,7 @@
#include common.h
#include command.h
#include net.h
+#include asm/unaligned.h
#include dns.h
@@ -109,7 +110,6 @@ DnsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src, unsigned len)
int found, stop, dlen;
char IPStr[22];
IPaddr_t IPAddress;
- short tmp;
debug(%s\n, __func__);
@@ -120,14 +120,14 @@ DnsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src, unsigned len)
debug(0x%p - 0x%.2x 0x%.2x 0x%.2x 0x%.2x\n,
pkt+i, pkt[i], pkt[i+1], pkt[i+2], pkt[i+3]);
- /* We sent 1 query. We want to see more that 1 answer. */
+ /* We sent one query. We want to have a single answer: */
header = (struct header *) pkt;
if (ntohs(header-nqueries) != 1)
return;
/* Received 0 answers */
if (header-nanswers == 0) {
- puts(DNS server returned no answers\n);
+ puts(DNS: host not found\n);
NetState = NETLOOP_SUCCESS;
return;
}
@@ -139,9 +139,8 @@ DnsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src, unsigned len)
continue;
/* We sent query class 1, query type 1 */
- tmp = p[1] | (p[2] 8);
- if (p[5] e || ntohs(tmp) != DNS_A_RECORD) {
- puts(DNS response was not A record\n);
+ if (p[5] e || get_unaligned_be16(p+1) != DNS_A_RECORD) {
+ puts(DNS: response was not an A record\n);
NetState = NETLOOP_SUCCESS;
return;
}
@@ -160,14 +159,12 @@ DnsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src, unsigned len)
}
debug(Name (Offset in header): %d\n, p[1]);
- tmp = p[2] | (p[3] 8);
- type = ntohs(tmp);
+ type = get_unaligned_be16(p+2);
debug(type = %d\n, type);
if (type == DNS_CNAME_RECORD) {
/* CNAME answer. shift to the next section */
debug(Found canonical name\n);
- tmp = p[10] | (p[11] 8);
- dlen = ntohs(tmp);
+ dlen = get_unaligned_be16(p+10);
debug(dlen = %d\n, dlen);
p += 12 + dlen;
} else if (type == DNS_A_RECORD) {
@@ -181,8 +178,7 @@ DnsHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src, unsigned len)
if (found p[12] e) {
- tmp = p[10] | (p[11] 8);
- dlen = ntohs(tmp);
+ dlen = get_unaligned_be16(p+10);
p += 12;
memcpy(IPAddress, p, 4);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi utility command support
On Wed 28 Jul 2010 10:01, shashikiran.bevenka...@wipro.com pondered: [snip] The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. Such disclaimers are inappropriate for mail sent to public lists. If your company automatically adds something like this to outgoing mail, and you can't convince them to stop, you might consider using a free web-based e-mail account. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch] ./net/net.c - make Microsoft dns servers happy with random_port() numbers
For some reason, (which I can't find any documentation on), if U-Boot
gives a port number higher than 17500 to a Microsoft DNS server, the
server will reply to port 17500, and U-Boot will ignore things (since
that isn't the port it asked the DNS server to reply to).
This fixes that by ensuring the random port number is less than 17500.
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
net/net.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/net.c b/net/net.c
index 595abd9..98d58e5 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1872,11 +1872,13 @@ void copy_filename (char *dst, char *src, int size)
#if defined(CONFIG_CMD_NFS) || defined(CONFIG_CMD_SNTP) ||
defined(CONFIG_CMD_DNS)
/*
- * make port a little random, but use something trivial to compute
+ * make port a little random (1024-17407)
+ * This keeps the math somewhat trivial to compute, and seems to work with
+ * all supported protocols/clients/servers
*/
unsigned int random_port(void)
{
- return 1024 + (get_timer(0) % 0x8000);;
+ return 1024 + (get_timer(0) % 0x4000);
}
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] About GPL
On Wed 16 Dec 2009 21:55, Rob Westfall pondered: Where exactly is the line for what you have to provide vs what you don't have to provide? We are building boards that are based on a standard board, but we have obviously had to modify include/config/boardname to setup for our hardware and create customized files to support our board. We have NOT modified files outside of customizing a /include/config/boardname and creating a board/boardname directory based on a existing board that is already released from the cpu vendor. The Free Software Foundation has this to say: http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add debug message for Blackfin Ethernet Rx function.
Add a simple print for the Blackfin's Ethernet Rx function, so we can debug incomming Ethernet functions easier. Signed-off-by: Robin Getz rg...@blackfin.uclinux.org --- drivers/net/bfin_mac.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c index 12d98c2..ec45b63 100644 --- a/drivers/net/bfin_mac.c +++ b/drivers/net/bfin_mac.c @@ -186,6 +186,9 @@ static int bfin_EMAC_recv(struct eth_device *dev) printf(Ethernet: bad frame\n); break; } + + debug(%s: len = %d\n, __func__, length - 4); + NetRxPackets[rxIdx] = (volatile uchar *)(rxbuf[rxIdx]-FrmData-Dest); NetReceive(NetRxPackets[rxIdx], length - 4); -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add Transfer Size Option to tftp
Optionally add RFC 2349 Transfer Size Option, so we can minimize the
time spent sending data over the UART (now print a single line during a
tftp transfer).
- If turned on (CONFIG_TFTP_TSIZE), U-Boot asks for the size of the file.
- if receives the file size, a single line (50 chars) are printed.
one hash mark == 2% of the file downloaded.
- if it doesn't receive the file size (the server doesn't support RFC
2349, prints standard hash marks (one mark for each UDP frame).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
net/tftp.c | 42 --
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 0fa7033..865f41a 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -56,6 +56,10 @@ static ulong TftpLastBlock; /* last packet sequence
number received */
static ulong TftpBlockWrap; /* count of sequence number wraparounds
*/
static ulong TftpBlockWrapOffset;/* memory offset due to wrapping
*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* The file size reported by the server
*/
+static short TftpNumchars; /* The number of hashes we printed
*/
+#endif
#define STATE_RRQ 1
#define STATE_DATA 2
@@ -202,6 +206,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ memcpy((char *)pkt, tsize\\0, 8);
+ pkt += 8;
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -311,8 +319,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
+#endif
}
#ifdef CONFIG_MCAST_TFTP
parse_multicast_oack((char *)pkt,len-1);
@@ -338,7 +352,16 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
TftpBlockWrap++;
TftpBlockWrapOffset += TftpBlkSize * TFTP_SEQUENCE_SIZE;
printf (\n\t %lu MB received\n\t ,
TftpBlockWrapOffset20);
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+ while (TftpNumchars NetBootFileXferSize * 50 /
TftpTsize) {
+ putc('#');
+ TftpNumchars++;
+ }
+ }
+#endif
+ else {
if (((TftpBlock - 1) % 10) == 0) {
putc ('#');
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
@@ -432,6 +455,13 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
+#ifdef CONFIG_TFTP_TSIZE
+ /* Print out the hash marks for the last packet
received */
+ while (TftpTsize TftpNumchars 49) {
+ putc('#');
+ TftpNumchars++;
+ }
+#endif
puts (\ndone\n);
NetState = NETLOOP_SUCCESS;
}
@@ -561,6 +595,10 @@ TftpStart (void)
#ifdef CONFIG_MCAST_TFTP
mcast_cleanup();
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+ TftpNumchars = 0;
+#endif
TftpSend ();
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Thu 13 Aug 2009 18:01, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200908131747.20194.rg...@blackfin.uclinux.org you wrote:
The better thing to do (IMHO) - would be to print out the proper number of
hashes, depending on the size of the file (and implement RFC 2349 at the
same
time) - not the number of packets (which is what happens today)...
Agreed. Patches welcome!
Something like this?
- If turned on (CONFIG_TFTP_TSIZE), asks for the size of the file.
- if receives the file size, prints out the percentage of the file
downloaded.
- when done, prints 100%
- if it doesn't receive the file size (the server doesn't support RFC
2349, prints standard hash marks.
Comments welcome...
diff --git a/net/tftp.c b/net/tftp.c
index 9544691..56db247 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -66,6 +66,9 @@ static ulong TftpLastBlock; /* last packet sequence
number received */
static ulong TftpBlockWrap; /* count of sequence number wraparounds
*/
static ulong TftpBlockWrapOffset;/* memory offset due to wrapping
*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* Tsize */
+#endif
#define STATE_RRQ 1
#define STATE_DATA 2
@@ -212,6 +215,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ pkt += sprintf((char *)pkt,tsize%c%d, 0,0);
+ pkt += strlen((char *)pkt) + 1;
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -321,8 +328,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
+#endif
}
#ifdef CONFIG_MCAST_TFTP
parse_multicast_oack((char *)pkt,len-1);
@@ -348,7 +361,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
TftpBlockWrap++;
TftpBlockWrapOffset += TftpBlkSize * TFTP_SEQUENCE_SIZE;
printf (\n\t %lu MB received\n\t ,
TftpBlockWrapOffset20);
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+
+ printf(%2d\b\b, NetBootFileXferSize * 100 /
TftpTsize);
+ }
+#endif
+ else {
if (((TftpBlock - 1) % 10) == 0) {
puts_quiet(#);
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
@@ -442,6 +462,11 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
+#ifdef CONFIG_TFTP_TSIZE
+ if (TftpTsize)
+ puts(100%);
+#endif
+
puts_quiet(\ndone\n);
#ifdef CONFIG_TFTP_TIME
end_time = get_timer(0);
@@ -550,6 +579,9 @@ TftpStart (void)
#ifdef CONFIG_TFTP_TIME
start_time = get_timer(0);
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+#endif
TftpTimeoutMSecs = TftpRRQTimeoutMSecs;
TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Sat 8 Aug 2009 05:50, Ben Warren pondered: Allesandro, Alessandro Rubini wrote: I finally fixed the defrag code, testing with NFS as well. Didn't take performance figures, tough, for lack of time. I wanted to do config + environment for the NFS case, like tftp, but didnt' do the second step out of laziness (also, the source file has long lines while I have 80 columns). For the record, I added the check on ip_src and ip_dst, but everything stopped working. So I reverted that instead of entering a long debugging session. The CONFIG_NET_MAXDEFRAG argument is the actual payload, so I add NFS overhead to that figure, which is expected to a beautiful 4096 or 8192. I feel this is better than other options, as the person writing the config is not expected to know how much protocol overhead is there. Alessandro Rubini (4): net: defragment IP packets tftp: get the tftp block size from config file and from the environment I noticed that while playing with this, that if you set the tftpblocksize environment, do a transfer, and then clear it, it does not go back to the default setting. I was not sure if this was the intended or not, but this fixes it (and provides a small code size reduction when this option is not activated). Also wondering -- if the user sets the tftpblocksize to a number larger than IP_MAXUDP, the transfer will never finish. Should this be restricted here? diff --git a/net/tftp.c b/net/tftp.c index 9544691..56db247 100644 --- a/net/tftp.c +++ b/net/tftp.c +#ifdef CONFIG_TFTP_BLOCKSIZE /* Allow the user to choose tftpblocksize */ if ((ep = getenv(tftpblocksize)) != NULL) TftpBlkSizeOption = simple_strtol(ep, NULL, 10); + else + TftpBlkSizeOption = TFTP_MTU_BLOCKSIZE; debug(tftp block size is %i\n, TftpBlkSizeOption); +#endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Mon 17 Aug 2009 15:05, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200908171315.40365.rg...@blackfin.uclinux.org you wrote:
Comments welcome...
I guess the code is largely untested?
I tested it on a single machine.
diff --git a/net/tftp.c b/net/tftp.c
index 9544691..56db247 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -66,6 +66,9 @@ static ulong TftpLastBlock; /* last packet
sequence number received */
static ulong TftpBlockWrap; /* count of sequence number
wraparounds */
static ulong TftpBlockWrapOffset;/* memory offset due to
wrapping*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* Tsize */
+#endif
Why static int? This gives a random init value for the second and each
following TFTP transfers.
Nope - it is set to zero on the start of every transfer.
@@ -212,6 +215,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ pkt += sprintf((char *)pkt,tsize%c%d, 0,0);
+ pkt += strlen((char *)pkt) + 1;
Looks to me as if you were adding the length twice?
One zero is for the null char (delimiter), one zero is for ascii zero (length).
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -321,8 +328,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
It seems you rely on TftpTsize to be zero otherwise. The current code
(with a static int) does not guarantee that, though.
It is set to zero below on start.
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+
+ printf(%2d\b\b, NetBootFileXferSize * 100 /
TftpTsize);
+ }
+#endif
Hm... maybe we should rather print hashes (say one '#' for each 2%,
resulting in a maximum of 50 characters output.
Otherwise we actually increase the amount of characters sent over the
serial line (and the intention was to reduce it, right?)
Yeah, it was to reduce the output - this was easier :)
Plus spinning numbers are always nice. When you are doing a scp - do you
look at the bar moving, or the numbers going up to 100%? I always look
at the numbers...
I'll re-work it for a single line of 50 hashes. (one '#' == 2% of the file).
+#ifdef CONFIG_TFTP_TSIZE
+ if (TftpTsize)
+ puts(100%);
+#endif
+
puts_quiet(\ndone\n);
Here we see the bad consequences of this puts_quiet() stuff (which I
really dislike. The longer I see it, the more I tend to reject it.
Here, the (necessary!) newline terminating the 100% output, is not
always sent, only when puts_quiet() is active.
Yeah, sorry about that - I would switch the puts to the puts_quiet
if that is picked up - I just never heard an ack or nack on it...
@@ -550,6 +579,9 @@ TftpStart (void)
#ifdef CONFIG_TFTP_TIME
start_time = get_timer(0);
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+#endif
Ah. I see :-)
So - you are OK with they way it is done (other comments still apply of
course).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Mon 17 Aug 2009 16:20, Wolfgang Denk pondered: Dear Robin Getz, In message 200908171555.31016.rg...@blackfin.uclinux.org you wrote: Why static int? This gives a random init value for the second and each following TFTP transfers. Nope - it is set to zero on the start of every transfer. Right, I saw this later, at the end of your patch, but was too lazy to change my whole message ;-) +#ifdef CONFIG_TFTP_TSIZE + pkt += sprintf((char *)pkt,tsize%c%d, 0,0); + pkt += strlen((char *)pkt) + 1; Looks to me as if you were adding the length twice? One zero is for the null char (delimiter), one zero is for ascii zero (length). Wel, the sprintf() already returns the number of output characters, i. e. 7. pkt then points at the terminating '\0' character. strlen() should always return 0, then. This makes not much sense to me. Also, why do you need sprintf() at all when the string is a constant anyway? Why not simply: memcpy (pkt, tsize\00, 7); pkt += 7; That's is better - It was just a dumb copy/paste from the blksize option... + printf(%2d\b\b, NetBootFileXferSize * 100 / TftpTsize); + } +#endif Hm... maybe we should rather print hashes (say one '#' for each 2%, resulting in a maximum of 50 characters output. Otherwise we actually increase the amount of characters sent over the serial line (and the intention was to reduce it, right?) Yeah, it was to reduce the output - this was easier :) Plus spinning numbers are always nice. When you are doing a scp - do you look at the bar moving, or the numbers going up to 100%? I always look at the numbers... I know what you mean. OTOH, I tend to dislike such characters sequences (with lots of backspace characters) because they always mess up log files ;-) But they look pretty ... :) I'll re-work it for a single line of 50 hashes. (one '#' == 2% of the file). Thanks. Np. So - you are OK with they way it is done (other comments still apply of course). Right. Thanks a lot. New version tomorrow... Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Wed 12 Aug 2009 16:04, Wolfgang Denk pondered: Dear Robin Getz, In message 200908121148.16431.rg...@blackfin.uclinux.org you wrote: Some info for the docs, when I was troubleshooting a Ubuntu 9.04 install. Good info, but bad format. Can you please submit this as a patch? There wasn't any existing docs to patch, and I thought that by the comment that Ben had made: On Mon 10 Aug 2009 15:57, Ben Warren pondered: Robin Getz wrote: Feel free to add my Signed-off (once the docs have been updated explaining what this is all for). I'll do that. Thanks for all your help. Was that he was going to add a patch for the docs... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Wed 12 Aug 2009 17:30, Wolfgang Denk pondered: Dear Ben Warren, In message 4a832bce.9060...@gmail.com you wrote: Sure, if you don't mind re-compiling. I think it might be an opt-outable message via puts_quiet() It seems we start having a mess here, with features bound to other features that have not even been agreeds about yet. I have to admit that I am no friend of this puts_quiet() thingy. How much time do we really save on a normal system? A small fraction. On a high speed network, with a low speed UART, and block sizes of 512 (default with BSD tftp). With printing hashes... uartDownload 57600 6657 (ms)2,734,393 (bytes/sec) Without 57600 6418 (ms)2,836,219 (bytes/sec) As the network gets faster, and the UART gets slower - it will make a bigger difference. Is this worth the inconsistent behaviour Most likely not. I'm not going to be offended if you NAK it. The better thing to do (IMHO) - would be to print out the proper number of hashes, depending on the size of the file (and implement RFC 2349 at the same time) - not the number of packets (which is what happens today)... and the (IMHO much uglier) code? The code isn't uglier - one function is replaced with a different one. The name of the function is kind of crappy - but that is what I came up with late one evening... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add md5sum and sha1 commands...
On Tue 11 Aug 2009 15:21, Wolfgang Denk pondered: Dear Robin Getz, In message 200908111357.25007.rg...@blackfin.uclinux.org you wrote: Now that we have sha1 and md5 in lib_generic, allow people to use them on the command line, for checking downloaded files Signed-off-by: Robin Getz rg...@blackfin.uclinux.org README |4 ++ common/cmd_mem.c | 68 + 2 files changed, 72 insertions(+) Wolfgang - was there anything wrong with this? or did you want me to send again? No, there is nothing wrog with it. Looks good to me. But it is new stuff, and the next branch is currently not so high on my priority list. Is this urgent to you? No - I was just going to update, and if I dropped it by accident (still learning git) - I wanted to make sure it was in your inbox... :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Jeff: Can you look at the recent changes to the net/next tree/branch? On a slow connection -- I saw things go from 15:28 download (tftpblocksize == 1468) to 1:47 (tftpblocksize == 16268) - more than a 8x difference. Even if you look at the your stated time of 50min - that should drop it to a more reasonable ~6ish ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add md5sum and sha1 commands...
On Mon 27 Jul 2009 00:07, Robin Getz pondered: From: Robin Getz rg...@blackfin.uclinux.org Now that we have sha1 and md5 in lib_generic, allow people to use them on the command line, for checking downloaded files Signed-off-by: Robin Getz rg...@blackfin.uclinux.org README |4 ++ common/cmd_mem.c | 68 + 2 files changed, 72 insertions(+) Wolfgang - was there anything wrong with this? or did you want me to send again? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Mon 10 Aug 2009 15:57, Ben Warren pondered: Robin Getz wrote: Thanks to Alessandro for putting it together. Feel free to add my Signed-off (once the docs have been updated explaining what this is all for). I'll do that. Thanks for all your help. Some info for the docs, when I was troubleshooting a Ubuntu 9.04 install. == It appears that some tftp servers (the older BSD version, Debian's tftpd) doesn't support RFC 2348 (blksize), and always use a block size of 512 :( You need to make sure that you install the the Peter Anvin version, which does support RFC 2348, and blksize up to 65,464 bytes (Debian's tftpd-hpa). http://www.kernel.org/pub/software/network/tftp/ How to tell which you have? Check your man page: man tftpd or ask for the version: Peter Anvin version: rg...@imhotep:~ /usr/sbin/in.tftpd -V tftp-hpa 0.48, with remap, with tcpwrappers rg...@imhotep:~ non-RFC 2348 one: rg...@imhotep:~ /usr/sbin/in.tftpd -V rg...@imhotep:~ Even when using the Peter Anvin version, block size can still be reduced via two methods: -B : limits the maximum permitted block size (-B 512) -r : rejects RFC 2347 TFTP options (-r blksize) Check your local /etc/xinetd.d/tftp or /etc/inetd.conf file to see how your tftpd server is being invoked. === -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make TFTP Quiet
On Wed 12 Aug 2009 15:48, Scott Wood pondered: On Wed, Aug 12, 2009 at 12:02:33PM +0200, Detlev Zundel wrote: Hi Timur, +#ifdef CONFIG_TFTP_QUIET +#define puts_quiet(fmt) +#else +#define puts_quiet(fmt) puts(fmt); +#endif This looks backwards to me. I would do this: #ifdef CONFIG_TFTP_QUIET #define puts(x) puts_quiet(x) #endif That way, you don't need to change all of the puts calls to puts_quiet. Plus, having the normal calls be puts_quiet that changes to puts when QUIET is *not* enabled just feels wrong. Just as a general remark - I consider it a bad idea to overload well known functions with non-standard behaviour. This breaks the principle of least surprise which turns out to be very valuable. Technically, U-Boot's puts() is already non-standard (no automatic newline)... But there's no redefinition in the original patch. It's just introducing a new puts_quiet(). Yeah, I think Detlev was just commenting on Timur's suggestion to the patch, not on the original patch... I would be happy to change things to a debugX() - but this changes everyone's default behaviour (it becomes opt in, not opt-out), and most likely would cause some puzzlement when normally things don't print like they use to... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Wed 12 Aug 2009 16:05, Ben Warren pondered: Hi Robin, Robin Getz wrote: On Mon 10 Aug 2009 15:57, Ben Warren pondered: Robin Getz wrote: Thanks to Alessandro for putting it together. Feel free to add my Signed-off (once the docs have been updated explaining what this is all for). I'll do that. Thanks for all your help. Some info for the docs, when I was troubleshooting a Ubuntu 9.04 install. == It appears that some tftp servers (the older BSD version, Debian's tftpd) doesn't support RFC 2348 (blksize), and always use a block size of 512 :( You need to make sure that you install the the Peter Anvin version, which does support RFC 2348, and blksize up to 65,464 bytes (Debian's tftpd-hpa): http://www.kernel.org/pub/software/network/tftp/ Maybe it would make sense to have a message printed if the user specifies a higher blocksize but the TFTP server doesn't respond to the 'blksize' request. Thoughts? It doesn't happen today... We request 1468 (today), and if don't get an respose to the blksize request, it falls back to 512 (with the BSD tftpd) - no message to the user - it just takes longer, and people complain about a crappy network driver... To me - this is independent of the defragmentation patch. If we request 1468 (MTU) or 1469 (which will be fragmented) - the logic in tftp.c is the same... There is already a debug(Blocksize ack... in the code - so I'm assuming that if someone wanted to figure it out - they just need to turn on DEBUG in tftp.c - rather than printing it out all the time... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Sat 8 Aug 2009 05:50, Ben Warren pondered: Allesandro, Alessandro Rubini wrote: I finally fixed the defrag code, testing with NFS as well. Didn't take performance figures, tough, for lack of time. Checking out performance with tftp - server is Linux 2.6.27 located in Germany, client (U-Boot running net/next) is located in the USA. Packets fragmented, and arriving out of order. U-Boot image (214268 bytes) tftpblocksize download rate (bytes) (ms) (bytes/second) 512 48,246 4,441 1024 24,482 8,752 1468 ( 1MTU) 17,24312,426 2048 12,51717,118 2948 ( 2MTU) 8,91224,042 4428 ( 3MTU) 6,16734,744 4096 6,60832,425 5908 ( 4MTU) 4,84044,270 7388 ( 5MTU) 4,04253,010 8192 3,64158,848 8868 ( 6MTU) 3,42562,560 10348 ( 7MTU) 2,97472,047 11828 ( 8MTU) 2,73678,314 13308 ( 9MTU) 2,50885,433 14788 (10MTU) 2,28193,935 16000 2,23395,955 16268 (11MTU) 2,17498,559 So, that is 17-seconds (default - on the master), to 2 seconds. Wow - a 87% reduction! Doing the same with a larger image (default kernel + ext2 file system == 12Meg), gets similar results - goes from 928,688 ms / 12,493 bytes/second (yeah, that is 15 minutes with a tftpblocksize == 1468) to 107,626 ms / 107,866 bytes/second (that is under two minutes with a tftpblocksize == 16000)... Again - an 88% reduction in time spent waiting... So - I think this is well worth the effort for those people who want to use tftp outside of a local network. (on a local network - things do not change that drastically - An 18Meg file with default tftpblocksize (1468 bytes) took 5084ms to download, and with a tftpblocksize of 16268, it about half the time - 2625 ms... Thanks to Alessandro for putting it together. Feel free to add my Signed-off (once the docs have been updated explaining what this is all for). -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Make TFTP Quiet
From bca49fb5e3045bc175e924999a4015804c39c5c6 Mon Sep 17 00:00:00 2001
From: Robin Getz rg...@blackfin.uclinux.org
I was using this when I was looking at some other recent tftp performance,
and thought I would share. I really don't think it belongs, as it is
(a) trivial and (b) mostly debug... (but I'm trying out some more things
with git).
This adds the ability to make tftp a little quieter, which saves some
time printing hash marks on the console. It also has the ability to
print some download stats for debugging network issues.
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
net/tftp.c | 29 -
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 0fa7033..9544691 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -22,6 +22,16 @@
/* (for checking the image size)
*/
#define HASHES_PER_LINE65 /* Number of loading hashes
per line */
+#ifdef CONFIG_TFTP_QUIET
+#define puts_quiet(fmt)
+#else
+#define puts_quiet(fmt)puts(fmt);
+#endif
+
+#ifdef CONFIG_TFTP_TIME
+static ulong start_time, end_time;
+#endif
+
/*
* TFTP operations.
*/
@@ -340,9 +350,9 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
printf (\n\t %lu MB received\n\t ,
TftpBlockWrapOffset20);
} else {
if (((TftpBlock - 1) % 10) == 0) {
- putc ('#');
+ puts_quiet(#);
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
- puts (\n\t );
+ puts_quiet(\n\t );
}
}
@@ -432,7 +442,12 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
- puts (\ndone\n);
+ puts_quiet(\ndone\n);
+#ifdef CONFIG_TFTP_TIME
+ end_time = get_timer(0);
+ printf(Time to download == %ld ms\n, end_time -
start_time);
+ printf(Download rate = %lld bytes/second\n, (long
long)(NetBootFileXferSize) * 1000 / (end_time - start_time));
+#endif
NetState = NETLOOP_SUCCESS;
}
break;
@@ -460,7 +475,7 @@ TftpTimeout (void)
#endif
NetStartAgain ();
} else {
- puts (T );
+ puts_quiet(T );
NetSetTimeout (TftpTimeoutMSecs, TftpTimeout);
TftpSend ();
}
@@ -530,7 +545,11 @@ TftpStart (void)
printf (Load address: 0x%lx\n, load_addr);
- puts (Loading: *\b);
+ puts_quiet(Loading: *\b);
+
+#ifdef CONFIG_TFTP_TIME
+ start_time = get_timer(0);
+#endif
TftpTimeoutMSecs = TftpRRQTimeoutMSecs;
TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make TFTP Quiet
On Mon 10 Aug 2009 16:55, Timur Tabi pondered: On Mon, Aug 10, 2009 at 3:26 PM, Robin Getzrg...@blackfin.uclinux.org wrote: --- a/net/tftp.c +++ b/net/tftp.c @@ -22,6 +22,16 @@ /* (for checking the image size) */ #define HASHES_PER_LINE 65 /* Number of loading hashes per line */ +#ifdef CONFIG_TFTP_QUIET +#define puts_quiet(fmt) +#else +#define puts_quiet(fmt) puts(fmt); +#endif This looks backwards to me. I would do this: #ifdef CONFIG_TFTP_QUIET #define puts(x) puts_quiet(x) #endif That way, you don't need to change all of the puts calls to puts_quiet. Plus, having the normal calls be puts_quiet that changes to puts when QUIET is *not* enabled just feels wrong. There are other puts that you don't want quiet... puts (Starting again\n\n); puts (\nRetry count exceeded; starting again\n); Otherwise - if you have a bad network - it will never output anything... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] minor debug cleanups in ./net
On Thu 23 Jul 2009 03:01, Robin Getz pondered:
OK - this is on
git remote -v
origin git://git.denx.de/u-boot-net.git
git log --max-count=1
commit 97cfe86163505ea18e7ff7b71e78df5bb03dad57
(Is there a better way to tell if git is up to date?)
Was there any problems with this one?
---
From: Robin Getz rg...@blackfin.uclinux.org
Minor ./net cleanups - no functional changes
- change #ifdef DEBUG printf(); #endif to just debug()
- changed __FUNCTION__ to __func__
- got rid of extra whitespace between function and opening brace
- removed unnecessary braces on if statements
gcc dead code elimination should make this functionally/size equivalent
when DEBUG is not defined. (confirmed on Blackfin, with gcc 4.3.3).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
diff --git a/net/Makefile b/net/Makefile
index 835a04a..ff87d87 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,7 +23,7 @@
include $(TOPDIR)/config.mk
-# CFLAGS += -DET_DEBUG -DDEBUG
+# CFLAGS += -DDEBUG
LIB = $(obj)libnet.a
diff --git a/net/bootp.c b/net/bootp.c
index d5f9c4b..0799ae2 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -8,17 +8,6 @@
* Copyright 2000-2004 Wolfgang Denk, w...@denx.de
*/
-#if 0
-#define DEBUG1 /* general debug */
-#define DEBUG_BOOTP_EXT 1/* Debug received vendor fields */
-#endif
-
-#ifdef DEBUG_BOOTP_EXT
-#define debug_ext(fmt,args...) printf (fmt ,##args)
-#else
-#define debug_ext(fmt,args...)
-#endif
-
#include common.h
#include command.h
#include net.h
@@ -107,7 +96,7 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest,
unsigned src, unsigned len)
retval = -6;
}
- debug (Filtering pkt = %d\n, retval);
+ debug(Filtering pkt = %d\n, retval);
return retval;
}
@@ -129,7 +118,7 @@ static void BootpCopyNetParams(Bootp_t *bp)
if (strlen(bp-bp_file) 0)
copy_filename (BootFile, bp-bp_file, sizeof(BootFile));
- debug (Bootfile: %s\n, BootFile);
+ debug(Bootfile: %s\n, BootFile);
/* Propagate to environment:
* don't delete exising entry when BOOTP / DHCP reply does
@@ -156,7 +145,7 @@ static void BootpVendorFieldProcess (u8 * ext)
{
int size = *(ext + 1);
- debug_ext ([BOOTP] Processing extension %d... (%d bytes)\n,
*ext,
+ debug([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
*(ext + 1));
NetBootFileSize = 0;
@@ -255,7 +244,7 @@ static void BootpVendorProcess (u8 * ext, int size)
{
u8 *end = ext + size;
- debug_ext ([BOOTP] Checking extension (%d bytes)...\n, size);
+ debug([BOOTP] Checking extension (%d bytes)...\n, size);
while ((ext end) (*ext != 0xff)) {
if (*ext == 0) {
@@ -269,34 +258,27 @@ static void BootpVendorProcess (u8 * ext, int
size)
}
}
-#ifdef DEBUG_BOOTP_EXT
- puts ([BOOTP] Received fields: \n);
+ debug([BOOTP] Received fields: \n);
if (NetOurSubnetMask)
- printf (NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
+ debug(NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
if (NetOurGatewayIP)
- printf (NetOurGatewayIP: %pI4,
NetOurGatewayIP);
+ debug(NetOurGatewayIP : %pI4, NetOurGatewayIP);
- if (NetBootFileSize) {
- printf (NetBootFileSize : %d\n, NetBootFileSize);
- }
+ if (NetBootFileSize)
+ debug(NetBootFileSize : %d\n, NetBootFileSize);
- if (NetOurHostName[0]) {
- printf (NetOurHostName : %s\n, NetOurHostName);
- }
+ if (NetOurHostName[0])
+ debug(NetOurHostName : %s\n, NetOurHostName);
- if (NetOurRootPath[0]) {
- printf (NetOurRootPath : %s\n, NetOurRootPath);
- }
+ if (NetOurRootPath[0])
+ debug(NetOurRootPath : %s\n, NetOurRootPath);
- if (NetOurNISDomain[0]) {
- printf (NetOurNISDomain : %s\n, NetOurNISDomain);
- }
+ if (NetOurNISDomain[0])
+ debug(NetOurNISDomain : %s\n, NetOurNISDomain);
- if (NetBootFileSize) {
- printf (NetBootFileSize: %d\n, NetBootFileSize);
- }
-#endif /* DEBUG_BOOTP_EXT */
+ if (NetBootFileSize)
+ debug(NetBootFileSize: %d\n, NetBootFileSize);
}
/*
* Handle a BOOTP received packet.
@@ -307,7 +289,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned
src, unsigned len)
Bootp_t *bp;
char*s;
- debug (got BOOTP packet (src=%d, dst=%d, len=%d
want_len=%zu)\n,
+ debug(got BOOTP packet (src=%d, dst=%d, len=%d
want_len=%zu)\n,
src, dest, len, sizeof (Bootp_t));
bp = (Bootp_t *)pkt;
@@ -330,7 +312,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned
src, unsigned len)
NetSetTimeout(0, (thand_f *)0);
- debug (Got
Re: [U-Boot] minor debug cleanups in ./net
On Thu 6 Aug 2009 15:40, Wolfgang Denk pondered: Dear Robin Getz, In message 200908061427.10961.rg...@blackfin.uclinux.org you wrote: On Thu 23 Jul 2009 03:01, Robin Getz pondered: OK - this is on git remote -v origin git://git.denx.de/u-boot-net.git git log --max-count=1 commit 97cfe86163505ea18e7ff7b71e78df5bb03dad57 (Is there a better way to tell if git is up to date?) Was there any problems with this one? Well, git describe needs less typing, and gives better information. Thanks for the tip. rg...@pinky:~/blackfin/mainline/u-boot/master git remote -v origin git://git.denx.de/u-boot.git rg...@pinky:~/blackfin/mainline/u-boot/master git describe --all HEAD^ warning: tag 'v2009.08-rc1' is really 'tags/v2009.08-rc1' here v2009.08-rc1-29-gc3fa4f0 when I switch to the net tree, I get: rg...@pinky:~/blackfin/mainline/u-boot/net git remote -v origin git://git.denx.de/u-boot-net.git rg...@pinky:~/blackfin/mainline/u-boot/net git describe --all HEAD^ warning: tag 'U-Boot-1_2_0' is really 'tags/U-Boot-1_2_0' here U-Boot-1_2_0-6291-g0b23fb3 That is because Ben hasn't done a git pull from the master since U-Boot-1_2_0? Or have I don't something wrong on my end? -robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered:
Thanks for your comments.
+#ifndef CONFIG_TFTP_MAXBLOCK
+#define CONFIG_TFTP_MAXBLOCK 16384
It is more than tftp - nfs could also use the same.
Yes, I know. But most users are tftp ones. And if you want an even
number (like 16k) as a tftp packet you need to add the headers and the
sequence count. And I prefer to have the useful number in the config.
So I used TFTP in the name in order for NFS users to know they must
make some calculation.
How about CONFIG_NET_MAXDEFRAG instead?
We could have MAXPAYLOAD if we count in NFS overhead as well (I don't
know how much it is, currently. Hope you see my point.
Not really.
IMHO - The protocol max payload should be taken care of on the protocol side,
not the common network side.
It then becomes:
#define TFTP_MTU_BLOCKSIZE (CONFIG_NET_MAXDEFRAG - TFTP_OVERHEAD)
#define NFS_READ_SIZE (CONFIG_NET_MAXDEFRAG - NFS_OVERHEAD)
or something like that (since NFS likes to be power of two, 1024, 2048, etc -
it would need to be tweaked a little), but you get the idea...
+static IP_t *__NetDefragment(IP_t *ip, int *lenp)
+{
I don't understand the purpose of the lenp.
The calling function doesn't use the len var, except for
ICMP_ECHO_REQUEST, which are not allowed to be fragmented.
I eliminated it - and suffered no side effects.
Well, since the caller has this len variable, I didn't want to leave
it corrupted. But if it's actually unused after this point, we can well
discard it.
OK.
+#else /* !CONFIG_IP_DEFRAG */
+
+static inline IP_t *NetDefragment(IP_t *ip, int *lenp)
+{
+ return ip;
+}
+#endif
This needs to have the same logic (ip_off (IP_OFFS | IP_FLAGS_MFRAG)) as
the above function. See comment below.
Yes, correct. Thanks.
Were you going to send an update for Ben?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered: For some reason - why I'm ping flooding when tftping a large file (with large tftp block size) - things hang. If I set the block size to under the MTU - it works fine. Do you get the same? Didn't try, and I can't do that today. I suspect either your ping is over-mtu, so each new fragment triggers the above code, No ping is the default length. The default packet size is 56 bytes, which translates into 98 bytes on the wire (8 bytes of ICMP header data, 20 for the IP header, and another 14 for the MAC addresses) or simply your ether+uboot can't keep up with the data rate. That doesn't explain, why does it work, when there is no fragmentation??? What it looks like is there is something wrong with the main network loop - the system is so busy responding to pings, that it never sends the TFTP Block ACK when it should. As eaplained in the cover letter cover.1248943812.git.rub...@unipv.it some fragments can be lost in high traffic, as polling mode doesn't allow to enqueue packets. So I think you just loose some fragments, as target CPU time is eaten by the ping packets, and you don't get the complete reassembled packet any more. I'm pretty sure it's like this. I'm not convinced yet - but need to do some further poking on a different network... On the other hand, I found a minor issue in this situation: - start a tftp transfer - ctrl-C it - start another Server retransmissions for the first transfer go into the defrag engine e that reset-defrag-data code is triggered, so a packet may be lost, and I get a sporadic T in the receiving u-boot. I think it's not a real problem, though --- or, now that I rethink about it, it can be the same issue as above: my ether can't enqueue 8k of stuff so a fragment is lost in that case. What is missing in the reassembly code (that is described in RFC815) is the timer. (quote from the RFC): -- The final part of the algorithm is some sort of timer based mechanism which decrements the time to live field of each partially reassembled datagram, so that incomplete datagrams which have outlived their usefulness can be detected and deleted. -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Fri 31 Jul 2009 08:16, Alessandro Rubini pondered: or simply your ether+uboot can't keep up with the data rate. That doesn't explain, why does it work, when there is no fragmentation??? Well, with no fragmentation there is less traffic. Each tftp packet is one patch, instead of a burst of packets (intermixed with pings). Is the target replying to all pings? Yes. And I can see the same in wireshark. Or is it loosing some? No. If it looses say 30%, I expect one fragment in 3 to be lost as well. If your big-tftp is 4 fragments, 20% passes it loss is equally spread ((2/3)^4), but I fear much less as the burst saturates the incoming queue. I'm pretty sure it's like this. I'm not convinced yet - but need to do some further poking on a different network... Thanks for these tests, mine is just guessing. No problem. I want to make sure it is robust as well. What is missing in the reassembly code (that is described in RFC815) is the timer. (quote from the RFC): -- The final part of the algorithm is some sort of timer based mechanism which decrements the time to live field of each partially reassembled datagram, so that incomplete datagrams which have outlived their usefulness can be detected and deleted. -- But I reassemble one packet only, so I don't need to timeout partly-filled packets to recover memory. But it is for the state that you described - the user cntr-C a current transfer, and the reassembly algorithm doesn't know to throw away a partially accepted packet, when things are cancelled... A soon as I have a fragment for a new packet, the old packet is discarded (while unfragmented stuff flies intermixed). Which works when you receive a complete fragment. As you indicated - what really happens is it causes a timeout on the first packet. Up to you if you want to handle this or not... All that should be needed is just to clear things in the start of NetLoop() (before eth_init) - there are a few things in there for CONFIG_NET_MULTI already, so I don't think that is a big deal... (That becomes your timer - a one shot at the very beginning of the transfer :) -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Fri 31 Jul 2009 10:02, Alessandro Rubini pondered: Is the target replying to all pings? Yes. And I can see the same in wireshark. Ah. I see. Strange... What is missing in the reassembly code (that is described in RFC815) is the timer. (quote from the RFC): -- The final part of the algorithm is some sort of timer based mechanism which decrements the time to live field of each partially reassembled datagram, so that incomplete datagrams which have outlived their usefulness can be detected and deleted. -- But I reassemble one packet only, so I don't need to timeout partly-filled packets to recover memory. But it is for the state that you described - the user cntr-C a current transfer, and the reassembly algorithm doesn't know to throw away a partially accepted packet, when things are cancelled... No, it's not like that. Are you sure? That is how it is on my network/tftp server. Maybe we are talking about different things. What I'm talking about is: - start a tftp file transfer. - CNTR-C it, causing a partial reassembly to done. - start a new transfer. All I did was add this to the start of NetLoop() to ensure that things are OK. #ifdef CONFIG_IP_DEFRAG memset(pkt_buff, 0, IP_HDR_SIZE_NO_UDP); #endif The old instance of the TFTP server resends the last packet of the aborted xfer, I don't see how this can happen. the tftp server gets a request for a block of 2048 bytes (for example) - and whacks out all 2048 bytes at once, and waits for the ACK. If the ACK never comes - it doesn't send the packet again. The client times out, and the client needs to send another ACK of the last block before it. What tftp server are you using? imhotep:/home/rgetz # /usr/sbin/in.tftpd -V tftp-hpa 0.43, with remap, with tcpwrappers while the new server sends the new packet. Both packets are new, they just come as intermixed fragments. And none survives as there is only one reassembly buffer. The only way this should happen - is a real attack - sending malformed packets to the U-Boot system while it is downloading things on the net - which I agree with your comments below - is outside the scope of what we are talking about. As a minimal test - since we are only talking about tftp and nfs (so far) - if we did not attempt to assemble packets which are not coming from the serverip, that might be an OK thing to do... if (NetReadIP(ip-ip_src) != NetServerIP) Or something like that, but both are fresh fragmented packets, no timeout would solve this sporadic problem. I still don't understand the use case. The server should only be sending packets in response to an ACK. The packets should be the entire UDP block size. the server should never mix packets. It seems to me that if we want a secure defagment system (one that can be use to net-boot production systems in hostile networks), it's going to be too complex. It could work well, however, as a faster tool for the interactive developer. I don't want something that is secure - security is beyond tftp's ability. For that -- you need to boot an OS and use https or sftp. All I'm asking for is something robust... :) -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered: For some reason - why I'm ping flooding when tftping a large file (with large tftp block size) - things hang. If I set the block size to under the MTU - it works fine. Do you get the same? Didn't try, and I can't do that today. I suspect either your ping is over-mtu, so each new fragment triggers the above code, or simply your ether+uboot can't keep up with the data rate. I tried on a different network (tftp a 18M file) - and it worked without issues while ping flooding... Until I filled up the max number of packets on the target (and it did start loosing things). sudo ping -l 3 -f targetip worked fine while transferring the file... sudo ping -l 4 -f targetip made things fall over - but this is a function of the ethernet driver, not anything else. (We pre-allocate 4 packets worth of info, and and only allow 4 packets to stack up). Even when there is no fragmentation - this causes it to fail So, I'll have to see what is going on with my network at home - so it could just be the network couldn't keep up... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] uboot-doc User's Manual Generation Tool
On Thu 30 Jul 2009 14:45, Wolfgang DenkVersion 1.3 pondered: Hi, In message m2eiryebkk@ohwell.denx.de Detlev Zundel wrote: ... Not meaning to interpret licensing, but to me that means I can't copy/paste sections into end product documentation, and ship the product for a fee... That's how it is currently, yes. Was that the intent? Not really - but I'll better let Wolfgang answer that question as he came up with the original licence text. Originally this actualy has been my intent. But that was a long, long time ago, back when I was writing all these documentation only by myself. It is on my priority list however to assemble a list of all contributors and ask them if they agree to relicence their contributions under the FDL. Consider my permission as granted :-) I assume - no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts? or did you desire something else? Since Front-Cover Text is limited to 5 words, and Back-Cover Text is limited to 25 words - how about (as Back-Cover Text) This manual includes sections from the Das U-Boot documentation, which can be found at http://www.denx.de/wiki/U-Boot and is copyright it's authors. Included under the Free Documentation License (v1.3) ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: defragment IP packets
On Thu 30 Jul 2009 05:02, Alessandro Rubini pondered:
The defragmenting code is enabled by CONFIG_IP_DEFRAG. The code
is useful for TFTP transfers, so the static reassembly buffer is sized
based on CONFIG_TFTP_MAXBLOCK (default is 16kB).
The packet buffer is used as an array of hole structures, acting as
a double-linked list. Each new fragment can split a hole in two,
reduce a hole or fill a hole. No support is there for a fragment
overlapping two diffrent holes (i.e., thre new fragment is across an
already-received fragment).
The code includes a number of suggestions by Robin Getz.
Signed-off-by: Alessandro Rubini rub...@gnudd.com
---
net/net.c | 172
+++--
1 files changed, 167 insertions(+), 5 deletions(-)
diff --git a/net/net.c b/net/net.c
index 641c37c..be382dd 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1117,6 +1117,164 @@ static void CDPStart(void)
}
#endif
+#ifdef CONFIG_IP_DEFRAG
+/*
+ * This function collects fragments in a single packet, according
+ * to the algorithm in RFC815. It returns NULL or the pointer to
+ * a complete packet, in static storage
+ */
+#ifndef CONFIG_TFTP_MAXBLOCK
+#define CONFIG_TFTP_MAXBLOCK 16384
It is more than tftp - nfs could also use the same.
How about CONFIG_NET_MAXDEFRAG instead?
+#endif
+#define IP_PAYLOAD (CONFIG_TFTP_MAXBLOCK + 4)
+#define IP_PKTSIZE (IP_PAYLOAD + IP_HDR_SIZE_NO_UDP)
+
+/*
+ * this is the packet being assembled, either data or frag control.
+ * Fragments go by 8 bytes, so this union must be 8 bytes long
+ */
+struct hole {
+ /* first_byte is address of this structure */
+ u16 last_byte; /* last byte in this hole + 1 (begin of next hole) */
+ u16 next_hole; /* index of next (in 8-b blocks), 0 == none */
+ u16 prev_hole; /* index of prev, 0 == none */
+ u16 unused;
+};
+
+static IP_t *__NetDefragment(IP_t *ip, int *lenp)
+{
I don't understand the purpose of the lenp.
The calling function doesn't use the len var, except for ICMP_ECHO_REQUEST,
which are not allowed to be fragmented.
I eliminated it - and suffered no side effects.
+ static uchar pkt_buff[IP_PKTSIZE] __attribute__((aligned(PKTALIGN)));
+ static u16 first_hole, total_len;
+ struct hole *payload, *thisfrag, *h, *newh;
+ IP_t *localip = (IP_t *)pkt_buff;
+ uchar *indata = (uchar *)ip;
+ int offset8, start, len, done = 0;
+ u16 ip_off = ntohs(ip-ip_off);
+
+ /* payload starts after IP header, this fragment is in there */
+ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE_NO_UDP);
+ offset8 = (ip_off IP_OFFS);
+ thisfrag = payload + offset8;
+ start = offset8 * 8;
+ len = ntohs(ip-ip_len) - IP_HDR_SIZE_NO_UDP;
+
+ if (start + len IP_PAYLOAD) /* fragment extends too far */
+ return NULL;
+
+ if (!total_len || localip-ip_id != ip-ip_id) {
+ /* new (or different) packet, reset structs */
+ total_len = 0x;
+ payload[0].last_byte = ~0;
+ payload[0].next_hole = 0;
+ payload[0].prev_hole = 0;
+ first_hole = 0;
+ /* any IP header will work, copy the first we received */
+ memcpy(localip, ip, IP_HDR_SIZE_NO_UDP);
+ }
I'm not sure the reset if we loose a packet, or get a bad one - start over is
a great idea.
For some reason - why I'm ping flooding when tftping a large file (with large
tftp block size) - things hang. If I set the block size to under the MTU - it
works fine. Do you get the same?
I'm still poking to figure out why...
+ /*
+ * What follows is the reassembly algorithm. We use the payload
+ * array as a linked list of hole descriptors, as each hole starts
+ * at a multiple of 8 bytes. However, last byte can be whaever value,
+ * so it is represented as byte count, not as 8-byte blocks.
+ */
+
+ h = payload + first_hole;
+ while (h-last_byte start) {
+ if (!h-next_hole) {
+ /* no hole that far away */
+ return NULL;
+ }
+ h = payload + h-next_hole;
+ }
+
+ if (offset8 + (len / 8) = h - payload) {
+ /* no overlap with holes (dup fragment?) */
+ return NULL;
+ }
+
+ if (!(ip_off IP_FLAGS_MFRAG)) {
+ /* no more fragmentss: truncate this (last) hole */
+ total_len = start + len;
+ h-last_byte = start + len;
+ }
+
+ /*
+ * There is some overlap: fix the hole list. This code doesn't
+ * deal with a fragment that overlaps with two different holes
+ * (thus being a superset of a previously-received fragment).
+ */
+
+ if ( (h = thisfrag) (h-last_byte = start + len) ) {
+ /* complete overlap with hole: remove hole */
+ if (!h-prev_hole !h-next_hole
Re: [U-Boot] [RFC 0/3] uboot-doc User's Manual Generation Tool
On Thu 30 Jul 2009 15:55, Wolfgang Denk pondered: Dear Robin Getz, In message 200907301550.40651.rg...@blackfin.uclinux.org you wrote: I assume - no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts? or did you desire something else? We don't have such detailed plans yet. Depending on the exact final plans, Analog Devices would be happy to donate anything from the U-Boot documentation we have created over the past few years https://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot While the examples are Blackfin specific, most should be generic enough to ensure that the reader should understand what to do on their architecture. We see maintaining something separate a duplication of effort, and wasted resources spent on documentation creation (which is a task most developers don't like anyways)... I think Mike brought this up awhile ago - http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg04491.html Which gets back to the original question... On Thu, 17 Apr 2008 11:02:18 -0700 Mike Frysinger pondered: On Thursday 17 April 2008, Detlev Zundel wrote: Hi Mike, On Monday 14 April 2008, Detlev Zundel wrote: we maintain a Blackfin-specific u-boot wiki that goes into quite a bit of detail, some of which is duplicated with the main u-boot wiki. how do people feel about extending the u-boot wiki to allow for arch-specific details ? What exactly do you have in mind? I surely don't see any principal problem here. It would certainly be valuable to get all U-Boot related info collected in a central place and have pointers wherever that make sense... from my reading of the wiki, it's more of a technical/command reference than a guide. the wiki we maintain is geared to be more of a guide. i think the two can be merged, i just dont want to convert things only to find out people dont want to take it that direction. Just to be clear, we are discussing the DULG wiki, right? is there any other worth talking about :) I agree that in the current state the documentation is more a reference but IIRC that wasn't really a conscious design decision. It simply turned out this way in the end. So I do not see any general problem in adding guide style sections in there. Maybe then most of the current documentation can then be shifted to a commands reference section. OK One problem I see though is how to correctly adapt such sections to the board specific nature of the DULG. Hopefully we can get away with mostly generic text passages and only a few ifdefs. It would be very helpful to know more concrete plans (outline!) to think further about these implications. Are there any thoughts about this? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] uboot-doc User's Manual Generation Tool
On Tue 28 Jul 2009 17:27, Wolfgang Denk pondered: Dear John, in message 1248813631.3915.102.ca...@johns you wrote: It seems to me that DUTS is designed to test U-Boot and also automates the running of commands whose output can be put online in the DULG. I Correct. And the DULG itself is a wiki (TWiki at the moment, to be converted to Foswiki ASAP) based framework which holds the static parts of the documentation. While we are on the topics of wikis, and U-Boot docs, can we discuss the license? http://www.denx.de/wiki/view/DULG/Introduction#Section_2.1. Since it is is not permitted to sell this document or the derivative work or to include it into any package or distribution that is not freely available to everybody. Not meaning to interpret licensing, but to me that means I can't copy/paste sections into end product documentation, and ship the product for a fee... Was that the intent? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Fri 24 Jul 2009 04:04, Alessandro Rubini pondered:
[snip]
+/* This only reassembles fragments that come in proper order */
+static inline IP_t *NetDefragment(IP_t *ip, int *lenp)
+{
+ static uchar pkt_buff[16384]; /*temporary arbitrary limit */
+ static int next_fragment;
+ static ushort pkt_id;
[snip]
+ /* further fragment: skip ip header (we miss offset_of...) */
+ memcpy(pkt_buff + next_fragment, pkt, len);
+ next_fragment += len;
Also (forgot last night) - we need to make sure the length of the packet fits
in the reassembly buffer before you do the memcpy(). Setting the tftp block
size to 16384 is bad if the buffer is also set to 16384.. (since it has the
IP header on it)...
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Mon 27 Jul 2009 01:08, Ben Warren pondered: Hi Guys, This is great work. Thanks! If you follow these guidelines, I'll pull it into the net repo: 1. Configurable block size (via a well-named CONFIG). Choose a good default value. 2. Handle out-of-order fragments, and some test results showing that it works. Are you OK with something that only has been tested with TFTP? Looks like nfs.h also has: /* Block size used for NFS read accesses. A RPC reply packet (including all * headers) must fit within a single Ethernet frame to avoid fragmentation. * Chosen to be a power of two, as most NFS servers are optimized for this. */ #define NFS_READ_SIZE 1024 3. Make the feature configurable 4. Test with a TFTP server that doesn't have blksize feature enabled It looks like the logic to do this is already there today - U-Boot uses a non-standard Block size (1468), and then falls back to 512 if it fails, or if the server doesn't ACK the option... I'm not sure about how to handle the configurability of this feature. I think there are two issues: - core networks stuff (CONFIG_NET_FRAG_SIZE defines the size of a reassembled packet, if it is not set, no reassembly code..) - default block size (if CONFIG_NET_FRAG_SIZE is defined, just read it from an env var?) or do you want a separate fixed CONFIG (and checks to make sure it is going to fit?) I can see this being the default configuration in the future, but for now it should probably be opt-in. Let's see how it goes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Mon 27 Jul 2009 08:41, Wolfgang Denk pondered: Dear Robin Getz, In message 200907262059.34188.rg...@blackfin.uclinux.org you wrote: ... and I was doing md5 or sha1 on things to make sure that things came over properly... Are you using FIT images, or reinventing the wheel? Neither - Blackfin does not support FIT yet - just doing a command line sha1sum $(loadaddr) $(filesize) (via the patch I sent yesterday). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Mon 27 Jul 2009 08:13, Alessandro Rubini pondered: Thanks for your comments. Should have a CONFIG_ something - to make this conditional. This has been asked by Ben too. Will do, although I'm not very happy about all those conditionals for every few lines of code. There are 22,250 #ifdef in the code base already - a few more isn't going to make thing any uglier than it already is. :) Some of your remarks are just symptoms of this being a quick hack, like the memcpy not checked, the missed getenv and so on. Yeah, comments were for completeness, not a comment on the (nice quick) function you put together... and I was doing md5 or sha1 on things to make sure that things came over properly... Yes, me too. Besides booting the stuff I got. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][Net] Convert SMC91111 Ethernet driver toCONFIG_NET_MULTI API
On Mon 27 Jul 2009 17:43, Ben Warren pondered:
All in-tree boards that use this controller have CONFIG_NET_MULTI
added
First - thanks.
Second - It's a style thing, but...
---
board/bf533-ezkit/bf533-ezkit.c | 12 +
include/netdev.h |1 +
71 files changed, 888 insertions(+), 490 deletions(-)
[snip]
diff --git a/board/bf533-ezkit/bf533-ezkit.c
b/board/bf533-ezkit/bf533-ezkit.c
index d5f0b7c..ff0e15e 100644
--- a/board/bf533-ezkit/bf533-ezkit.c
+++ b/board/bf533-ezkit/bf533-ezkit.c
@@ -26,6 +26,7 @@
*/
#include common.h
+#include netdev.h
#include psd4256.h
#include flash-defines.h
@@ -57,3 +58,14 @@ int misc_init_r(void)
return 0;
}
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC9
+ rc = smc9_initialize(0, CONFIG_SMC9_BASE);
+#endif
+ return rc;
+}
+#endif
[snip]
diff --git a/include/netdev.h b/include/netdev.h
index 3e66586..4636b57 100644
--- a/include/netdev.h
+++ b/include/netdev.h
@@ -73,6 +73,7 @@ int rtl8169_initialize(bd_t *bis);
int scc_initialize(bd_t *bis);
int skge_initialize(bd_t *bis);
int smc911x_initialize(u8 dev_num, int base_addr);
+int smc9_initialize(u8 dev_num, int base_addr);
int tsi108_eth_initialize(bd_t *bis);
int uec_initialize(int index);
int uec_standard_init(bd_t *bis);
would be alot less ifdefs if you put it in the header file...
#ifdef CONFIG_SMC9
int smc9_initialize(u8 dev_num, int base_addr);
#else
#define smc9_initialize(dev_num, base_addr) 0
#endif
that would remove all the ifdef CONFIG_SMC9 in all the board files...
also would not be required to set the initial value anymore either...
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][Net] Convert SMC91111 Ethernet driver to CONFIG_NET_MULTI API
On Mon 27 Jul 2009 17:47, Ben Warren pondered: Ben Warren wrote: All in-tree boards that use this controller have CONFIG_NET_MULTI added Also: - changed CONFIG_DRIVER_SMC9 to CONFIG_SMC9 - cleaned up line lengths - modified all boards that override weak function in this driver - modified all eeprom standalone apps to work with new driver Signed-off-by: Ben Warren biggerbadder...@gmail.com This patch is pretty big (~98k) and should probably be split up in its final incarnation. This is really meant as a test patch. Since I don't have boards with this chip family, I'm unable to test for anything beyond clean compiling. I don't have a blackfin toolchain installed, but it does build cleanly on 'MAKEALL ARM9' using ELDK 4.1 for ARM. If anybody is able to test, please do and let me know the results. I have a few boards in the office - I'll try tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][Net] Convert SMC91111 Ethernet driver to CONFIG_NET_MULTI API
On Mon 27 Jul 2009 17:47, Ben Warren pondered: Ben Warren wrote: All in-tree boards that use this controller have CONFIG_NET_MULTI added Also: - changed CONFIG_DRIVER_SMC9 to CONFIG_SMC9 - cleaned up line lengths - modified all boards that override weak function in this driver - modified all eeprom standalone apps to work with new driver Signed-off-by: Ben Warren biggerbadder...@gmail.com This patch is pretty big (~98k) and should probably be split up in its final incarnation. This is really meant as a test patch. Since I don't have boards with this chip family, I'm unable to test for anything beyond clean compiling. I don't have a blackfin toolchain installed, There are always tarballs and rpms (source and binaries) at: http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseBrowsefrs_package_id=127 but it does build cleanly on 'MAKEALL ARM9' using ELDK 4.1 for ARM. If anybody is able to test, please do and let me know the results. regards, Ben ___ 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] [PATCH][Net] Convert SMC91111 Ethernet driver toCONFIG_NET_MULTI API
On Mon 27 Jul 2009 18:17, Ben Warren pondered: I actually like to have them in the board C code. To the casual observer, it is obvious that certain ethernet controllers are optional, whereas if all they see is a string of initialization functions for different chips they might say, WTF?. Like I said - it is a style thing. less ifdefs is better in my opinion. Since you need to answer more questions about things - your way is OK too... Something like this is pretty easy to understand - and on modern compilers (anything over 3.x gcc) should compile to the same as yours (and I think is just as easy to understand for the casual reader) if (smc9_initialize(0, CONFIG_SMC9_BASE)) return 1; return 0; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Sun 26 Jul 2009 16:23, Alessandro Rubini pondered: http://www.faqs.org/rfcs/rfc815.html Yeah, I had seen this - but didn't want to duplicate something that Alessandro might already working on... Alessandro - were you going to add out of order packets? If the code has chances to go mainline, I'll be happy to complete this task. In the past - Wolfgang has normally said that as long as it doesn't negatively effect his platforms (i.e. is a compile option that doesn't effect the size of the normal build) he is mostly OK with anything (within reason). So unless I get a nak earlier, I'm going to find a time slot in the next few days (with your fixes, I suppose, or should they remain separate patches?) Nah - roll them all together... I'll send some comments to your earlier patch. To make your host send out of order/delayed packets, which should be more real world/long haul try something like: # modprobe sch_netem (if it's not compiled into your kernel) # tc qdisc change dev eth0 root netem reorder 50% delay 10ms Thanks a lot, I was missing that. http://www.linuxfoundation.org/en/Net:Netem#Packet_re-ordering Some of the examples do not work, and the tc errors are pretty much meaningless - the man page is pretty thin, but the command line tc qdisc change dev eth0 root netem help might get you what you need to test things. -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Fri 24 Jul 2009 04:04, Alessandro Rubini pondered:
This patch add a quick and dirty defrag step in IP reception. This
allows to increase the TFTP block size and get more performance in
slow links (but at that point it should be made configurable).
The overhead is negligible, verified with an ARM9 CPU and 10MB data
file, changing the server MTU from 1500 to 800 and then 550. However,
on a LAN connection, I didn't see advantes with using a 4k block
size with default MTU.
Signed-off-by: Alessandro Rubini rub...@gnudd.com
---
This patch is over mainline, without the (much appreciated) cleanup
patch that reached the list these days.
net/net.c | 46 ++
1 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/net/net.c b/net/net.c
index 641c37c..5034a2e 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1117,6 +1117,46 @@ static void CDPStart(void)
}
#endif
Should have a CONFIG_ something - to make this conditional.
+/* This only reassembles fragments that come in proper order */
+static inline IP_t *NetDefragment(IP_t *ip, int *lenp)
+{
+ static uchar pkt_buff[16384]; /*temporary arbitrary limit */
+ static int next_fragment;
+ static ushort pkt_id;
pkt_buff needs to be aligned - in case you want to start poking in it (which
you are going to want to do...) just add a:
__attribute__((aligned(PKTALIGN)));
+ #define IPSZ 20
I think what you want is IP_HDR_SIZE_NO_UDP - from include/net.h
+ uchar *pkt = (uchar *)ip;
+ ushort ip_off;
+ int offset, len = *lenp -2;
Some ethernet drivers are messed up, and provide bogus lengths (add a few
bytes that shouldn't be there).
It's better to get the length from the IP header. Adjusted to dump the header:
len = ntohs(ip-ip_len) - IP_HDR_SIZE_NO_UDP;
+ ip_off = ntohs(ip-ip_off);
+ if (!(ip_off (IP_OFFS | IP_FLAGS_MFRAG)))
+ return ip;
Why not do this in NetReceive()?
JMP/RTS are much more expensive on most archs than a if()
+ offset = (ip_off IP_OFFS) * 8;
+ if (!offset) { /* new packet begins, discard any we might have
*/
+ pkt_id = ip-ip_id;
+ memcpy(pkt_buff, ip, len);
+ next_fragment = len;
+ return NULL;
+ }
+
+ /* further fragment: discard IP header */
+ offset += IPSZ; len -= IPSZ; pkt += IPSZ;
+
+ if (ip-ip_id != pkt_id || offset != next_fragment)
+ return NULL; /* out of order */
We should check more than packet id - in case it is coming from a different
host...
if (ip-ip_id != (IP_t *)pkt_buff-ip_id || /* check the packet ID */
ip-ip_p != (IP_t *)pkt_buff-ip_p || /* check the protocol */
ip-ip_src != (IP_t *)pkt_buff-ip_src || /* check the source*/
ip-ip_dst != (IP_t *)pkt_buff-ip_dst ) /* check the dest */
+ /* further fragment: skip ip header (we miss offset_of...) */
+ memcpy(pkt_buff + next_fragment, pkt, len);
+ next_fragment += len;
+
+ if (ip_off IP_FLAGS_MFRAG)
+ return NULL; /* more expected */
+
+ *lenp = next_fragment;
+ return (IP_t *)pkt_buff;
+}
void
NetReceive(volatile uchar * inpkt, int len)
@@ -1360,6 +1400,8 @@ NetReceive(volatile uchar * inpkt, int len)
break;
case PROT_IP:
+ if (!(ip = NetDefragment(ip, len)))
+ return;
#ifdef ET_DEBUG
puts (Got IP\n);
#endif
I guess this is includes some generic cleanup - but at least the reassembly
should happen _after_ the sanity checks are done. Something like:
case PROT_IP:
#ifdef ET_DEBUG
puts (Got IP\n);
#endif
/* Before we start poking the header, make sure it is there */
if (len IP_HDR_SIZE) {
debug (len bad %d %lu\n, len, (ulong)IP_HDR_SIZE);
return;
}
/* can't deal with anything except IPv4 */
if ((ip-ip_hl_v 0xf0) != 0x40) {
debug(I only understand IPv4\n);
return;
}
/* can't deal with IP options (headers != 20 bytes) */
if ((ip-ip_hl_v 0x0f) * 4 != IP_HDR_SIZE_NO_UDP) {
debug(Can't deal with IP options\n);
return;
}
/* Check the Checksum of the header */
if (!NetCksumOk((uchar *)ip, IP_HDR_SIZE_NO_UDP / 2)) {
puts (IP header checksum bad\n);
return;
}
/* Check the packet length */
if (len ntohs(ip-ip_len)) {
printf(len bad %d %d\n, len, ntohs(ip-ip_len));
return;
}
/* If it is not for us, ignore it */
tmp = NetReadIP(ip-ip_dst);
Re: [U-Boot] [PATCH 1/2 V3] new video driver for bus vcxkframebuffers
On Sun 26 Jul 2009 07:46, Anatolij Gustschin pondered: Jens Scharsig wrote: This patch adds a new video driver * adds common bus_vcxk framebuffer driver Signed-off-by: Jens Scharsig e...@bus-elektronik.de Applied to u-boot-video. Thanks! Note that I had to fix lots of style issues before applying. Next time please use scripts/checkpatch.pl from the Linux source tree to check your patches before submitting them and resolve reported issues were it makes sence. Thanks. Is there a reason not to include the checkpatch.pl in http://www.denx.de/wiki/U-Boot/Patches or in the README (in the Submitting Patches section) if it is going to be a requirement? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add md5sum and sha1 commands...
From: Robin Getz rg...@blackfin.uclinux.org
Now that we have sha1 and md5 in lib_generic, allow people to use them
on the command line, for checking downloaded files
Signed-off-by: Robin Getz rg...@analog.com
README |4 ++
common/cmd_mem.c | 68 +
2 files changed, 72 insertions(+)
---
diff --git a/README b/README
index 9071472..cf3867d 100644
--- a/README
+++ b/README
@@ -629,6 +629,8 @@ The following options need to be configured:
CONFIG_CMD_KGDB * kgdb
CONFIG_CMD_LOADB loadb
CONFIG_CMD_LOADS loads
+ CONFIG_CMD_MD5SUM print md5 message digest
+ (requires CONFIG_CMD_MEMORY and
CONFIG_MD5)
CONFIG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base,
loop, loopw, mtest
CONFIG_CMD_MISC Misc functions like sleep etc
@@ -652,6 +654,8 @@ The following options need to be configured:
(requires CONFIG_CMD_I2C)
CONFIG_CMD_SETGETDCR Support for DCR Register access
(4xx only)
+ CONFIG_CMD_SHA1 print sha1 memory digest
+ (requires CONFIG_CMD_MEMORY)
CONFIG_CMD_SOURCE source command Support
CONFIG_CMD_SPI * SPI serial bus support
CONFIG_CMD_USB * USB support
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index cdf8c79..9850800 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -34,6 +34,9 @@
#endif
#include watchdog.h
+#include u-boot/md5.h
+#include sha1.h
+
#ifdef CMD_MEM_DEBUG
#definePRINTF(fmt,args...) printf (fmt ,##args)
#else
@@ -1141,6 +1144,55 @@ int do_mem_crc (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
}
#endif /* CONFIG_CRC32_VERIFY */
+#ifdef CONFIG_CMD_MD5SUM
+int do_md5sum(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ unsigned long addr, len;
+ unsigned int i;
+ u8 output[16];
+
+ if (argc 3) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ len = simple_strtoul(argv[2], NULL, 16);
+
+ md5((unsigned char *) addr, len, output);
+ printf(md5 for %08lx ... %08lx == , addr, addr + len - 1);
+ for (i = 0; i 16; i++)
+ printf(%02x, output[i]);
+ printf(\n);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_CMD_SHA1
+int do_sha1sum(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ unsigned long addr, len;
+ unsigned int i;
+ u8 output[20];
+
+ if (argc 3) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ len = simple_strtoul(argv[2], NULL, 16);
+
+ sha1_csum((unsigned char *) addr, len, output);
+ printf(SHA1 for %08lx ... %08lx == , addr, addr + len - 1);
+ for (i = 0; i 20; i++)
+ printf(%02x, output[i]);
+ printf(\n);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_CMD_UNZIP
int gunzip (void *, int, unsigned char *, unsigned long *);
@@ -1267,6 +1319,22 @@ U_BOOT_CMD(
);
#endif /* CONFIG_MX_CYCLIC */
+#ifdef CONFIG_CMD_MD5SUM
+U_BOOT_CMD(
+ md5sum, 3, 1, do_md5sum,
+ compute MD5 message digest,
+ address count
+);
+#endif
+
+#ifdef CONFIG_CMD_SHA1SUM
+U_BOOT_CMD(
+ sha1sum,3, 1, do_sha1sum,
+ compute SHA1 message digest,
+ address count
+);
+#endif /* CONFIG_CMD_SHA1 */
+
#ifdef CONFIG_CMD_UNZIP
U_BOOT_CMD(
unzip, 4, 1, do_unzip,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Add md5sum and sha1 commands...
From: Robin Getz rg...@blackfin.uclinux.org
Now that we have sha1 and md5 in lib_generic, allow people to use them on
the command line, for checking downloaded files
Signed-off-by: Robin Getz rg...@analog.com
README |4 ++
common/cmd_mem.c | 73 +
2 files changed, 77 insertions(+)
---
diff --git a/README b/README
index 9071472..cf3867d 100644
--- a/README
+++ b/README
@@ -629,6 +629,8 @@ The following options need to be configured:
CONFIG_CMD_KGDB * kgdb
CONFIG_CMD_LOADB loadb
CONFIG_CMD_LOADS loads
+ CONFIG_CMD_MD5SUM print md5 message digest
+ (requires CONFIG_CMD_MEMORY and
CONFIG_MD5)
CONFIG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base,
loop, loopw, mtest
CONFIG_CMD_MISC Misc functions like sleep etc
@@ -652,6 +654,8 @@ The following options need to be configured:
(requires CONFIG_CMD_I2C)
CONFIG_CMD_SETGETDCR Support for DCR Register access
(4xx only)
+ CONFIG_CMD_SHA1 print sha1 memory digest
+ (requires CONFIG_CMD_MEMORY)
CONFIG_CMD_SOURCE source command Support
CONFIG_CMD_SPI * SPI serial bus support
CONFIG_CMD_USB * USB support
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index cdf8c79..ac2492c 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -34,6 +34,14 @@
#endif
#include watchdog.h
+#ifdef CONFIG_CMD_MD5SUM
+#include u-boot/md5.h
+#endif
+
+#ifdef CONFIG_CMD_SHA1
+#include sha1.h
+#endif
+
#ifdef CMD_MEM_DEBUG
#definePRINTF(fmt,args...) printf (fmt ,##args)
#else
@@ -1141,6 +1149,55 @@ int do_mem_crc (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
}
#endif /* CONFIG_CRC32_VERIFY */
+#ifdef CONFIG_CMD_MD5SUM
+int do_md5sum(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ unsigned long addr, len;
+ unsigned int i;
+ u8 output[16];
+
+ if (argc 3) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ len = simple_strtoul(argv[2], NULL, 16);
+
+ md5((unsigned char *) addr, len, output);
+ printf(md5 for %08lx ... %08lx == , addr, addr + len - 1);
+ for (i = 0; i 16 ; i++)
+ printf(%02x, output[i]);
+ printf(\n);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_CMD_SHA1
+int do_sha1(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ unsigned long addr, len;
+ unsigned int i;
+ u8 output[20];
+
+ if (argc 3) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ len = simple_strtoul(argv[2], NULL, 16);
+
+ sha1_csum((unsigned char *) addr, len, output);
+ printf(SHA1 for %08lx ... %08lx == , addr, addr + len - 1);
+ for (i = 0; i 20 ; i++)
+ printf(%02x, output[i]);
+ printf(\n);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_CMD_UNZIP
int gunzip (void *, int, unsigned char *, unsigned long *);
@@ -1267,6 +1324,22 @@ U_BOOT_CMD(
);
#endif /* CONFIG_MX_CYCLIC */
+#ifdef CONFIG_CMD_MD5SUM
+U_BOOT_CMD(
+ md5sum, 3, 1, do_md5sum,
+ compute MD5 message digest,
+ address count
+);
+#endif
+
+#ifdef CONFIG_CMD_SHA1
+U_BOOT_CMD(
+ sha1, 3, 1, do_sha1,
+ compute SHA1 message digest,
+ address count
+);
+#endif /* CONFIG_CMD_SHA1 */
+
#ifdef CONFIG_CMD_UNZIP
U_BOOT_CMD(
unzip, 4, 1, do_unzip,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Fri 24 Jul 2009 04:04, Alessandro Rubini pondered:
This patch add a quick and dirty defrag step in IP reception. This
allows to increase the TFTP block size and get more performance in
slow links (but at that point it should be made configurable).
The overhead is negligible, verified with an ARM9 CPU and 10MB data
file, changing the server MTU from 1500 to 800 and then 550. However,
on a LAN connection, I didn't see advantes with using a 4k block
size with default MTU.
I do...
Filesize : 4613551 bytes (4.3Mbytes)
tftp modified, so it doesn't print out hashes (have have things slow down for
the UART printing) - to make sure we are getting a true network
measurement...
+#ifndef CONFIG_TFTP_QUIET
if (((TftpBlock - 1) % 10) == 0) {
putc ('#');
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0)
puts (\n\t );
+#endif
block size seconds
512 9.43 144.78% (+2.92 seconds)
1468 6.52 100.00% (default)
2048 6.27 96.20% (-0.25 seconds)
3072 5.69 87.40% (-0.82 seconds)
4096 5.46 83.81% (-1.05 seconds)
5120 5.26 80.76% (-1.25 seconds)
6144 5.13 78.79% (-1.38 seconds)
7168 5.09 78.13% (-1.42 seconds)
8192 5.01 76.92% (-1.50 seconds)
10240 4.94 75.83% (-1.58 seconds)
12288 4.87 74.74% (-1.65 seconds)
14336 4.85 74.49% (-1.66 seconds)
16384 4.82 73.95% (-1.70 seconds)
Saving that 1.7 seconds is worth it to me...
On a slower connection - I would guess that the difference is going to be more
dramatic...
I needed to modify your patch a little bit to get it working on my platform.
If Ben/Wolfgang are interested in taking this - I'll fix up my mods, and send
it back.
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add md5sum and sha1 commands...
On Sat 25 Jul 2009 22:49, Mike Frysinger pondered: On Saturday 25 July 2009 16:07:49 Robin Getz wrote: --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -34,6 +34,14 @@ #endif #include watchdog.h +#ifdef CONFIG_CMD_MD5SUM +#include u-boot/md5.h +#endif + +#ifdef CONFIG_CMD_SHA1 +#include sha1.h +#endif i dont think there would be a problem just including these all the time. would make it easier to notice problems down the line if people moved files and compile tested with boards that didnt enable these commands for example. I'm OK with either way. + for (i = 0; i 16 ; i++) no space before that semicolon + for (i = 0; i 20 ; i++) same here Oops. +#ifdef CONFIG_CMD_MD5SUM +U_BOOT_CMD( + md5sum, 3, 1, do_md5sum, + compute MD5 message digest, + address count +); +#endif + +#ifdef CONFIG_CMD_SHA1 +U_BOOT_CMD( + sha1, 3, 1, do_sha1, + compute SHA1 message digest, + address count +); +#endif /* CONFIG_CMD_SHA1 */ there's no need for these to be at the bottom of the file. move the U_BOOT_CMD() into the releated #ifdef block. I'm just doing the same as all the other things in the same file (which doesn't mean it is correct). What is the preferred style? also, they should both have a sum suffix or neither. i'd lean towards the former ... Will do. Since the standard Linux console commands are sha1sum md5sum I'll make U-Boot do like-wise. I'll send a new version, when Wolfgang lets me know what the ifdef preference is... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] net: defragment IP packets
On Sat 25 Jul 2009 22:02, Jerry Van Baren pondered: Robin Getz wrote: On Fri 24 Jul 2009 04:04, Alessandro Rubini pondered: This patch add a quick and dirty defrag step in IP reception. I needed to modify your patch a little bit to get it working on my platform. If Ben/Wolfgang are interested in taking this - I'll fix up my mods, and send it back. FWIIW, RFC815 describes a reassembly algorithm that handles out-of-order reassembly directly in the receive buffer by keeping the holes bookkeeping data in the holes themselves. http://www.faqs.org/rfcs/rfc815.html Yeah, I had seen this - but didn't want to duplicate something that Alessandro might already working on... Alessandro - were you going to add out of order packets? Since we are only really interested in TFTP (which still requires an ACK for a complete block), we should not need to handle more than one packet ID, so it should be mostly trivial... To make your host send out of order/delayed packets, which should be more real world/long haul try something like: # modprobe sch_netem (if it's not compiled into your kernel) # tc qdisc change dev eth0 root netem reorder 50% delay 10ms -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Fri 24 Jul 2009 04:11, Alessandro Rubini pondered: BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first? I believe it depends on if it your host has gig support (for jumbo frames) Most Gig hosts/routers/gateways nowadays do... http://en.wikipedia.org/wiki/Jumbo_frame However - it looks like it might be a bug in the Linux networking stack (I'll ask on netdev) that if the Gig card is connected as 100, it should not be sending jumbo frames (from what I understand -- it is a spec violation). I tried on my subnet - and was able to transfer 4k packets without issue (which is as big as I tested). (dumb repeater/hub between U-Boot the tftp server). However - my MAC running on U-Boot is 10/100 and does not support jumbo frames, and tosses the frame as a Frame too long, and is truncated to 1556 (0x614) bytes in all cases, so if the host is not fragmenting things properly - I can't test it... :( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] minor debug cleanups in ./net
On Thu 23 Jul 2009 02:27, Ben Warren pondered:
Robin,
This won't apply:
bwar...@bwarren-bldsrv:~/src/u-boot-net$ git am -s --whitespace=strip
~/h_drive/patches/minor\ debug\ cleanups\ in\ ._net.eml
Applying minor debug cleanups in ./net
fatal: patch fragment without header at line 198: @@ -879,13 +856,13 @@
DhcpHandler(uchar * pkt, unsigned dest, unsigned src, unsigned len)
Patch failed at 0001.
When you have resolved this problem run git-am --resolved.
If you would prefer to skip this patch, instead run git-am --skip.
OK - this is on
git remote -v
origin git://git.denx.de/u-boot-net.git
git log --max-count=1
commit 97cfe86163505ea18e7ff7b71e78df5bb03dad57
(Is there a better way to tell if git is up to date?)
---
From: Robin Getz rg...@blackfin.uclinux.org
Minor ./net cleanups - no functional changes
- change #ifdef DEBUG printf(); #endif to just debug()
- changed __FUNCTION__ to __func__
- got rid of extra whitespace between function and opening brace
- removed unnecessary braces on if statements
gcc dead code elimination should make this functionally/size equivalent
when DEBUG is not defined. (confirmed on Blackfin, with gcc 4.3.3).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
diff --git a/net/Makefile b/net/Makefile
index 835a04a..ff87d87 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,7 +23,7 @@
include $(TOPDIR)/config.mk
-# CFLAGS += -DET_DEBUG -DDEBUG
+# CFLAGS += -DDEBUG
LIB= $(obj)libnet.a
diff --git a/net/bootp.c b/net/bootp.c
index d5f9c4b..0799ae2 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -8,17 +8,6 @@
* Copyright 2000-2004 Wolfgang Denk, w...@denx.de
*/
-#if 0
-#define DEBUG 1 /* general debug */
-#define DEBUG_BOOTP_EXT 1 /* Debug received vendor fields */
-#endif
-
-#ifdef DEBUG_BOOTP_EXT
-#define debug_ext(fmt,args...) printf (fmt ,##args)
-#else
-#define debug_ext(fmt,args...)
-#endif
-
#include common.h
#include command.h
#include net.h
@@ -107,7 +96,7 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned
src, unsigned len)
retval = -6;
}
- debug (Filtering pkt = %d\n, retval);
+ debug(Filtering pkt = %d\n, retval);
return retval;
}
@@ -129,7 +118,7 @@ static void BootpCopyNetParams(Bootp_t *bp)
if (strlen(bp-bp_file) 0)
copy_filename (BootFile, bp-bp_file, sizeof(BootFile));
- debug (Bootfile: %s\n, BootFile);
+ debug(Bootfile: %s\n, BootFile);
/* Propagate to environment:
* don't delete exising entry when BOOTP / DHCP reply does
@@ -156,7 +145,7 @@ static void BootpVendorFieldProcess (u8 * ext)
{
int size = *(ext + 1);
- debug_ext ([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
+ debug([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
*(ext + 1));
NetBootFileSize = 0;
@@ -255,7 +244,7 @@ static void BootpVendorProcess (u8 * ext, int size)
{
u8 *end = ext + size;
- debug_ext ([BOOTP] Checking extension (%d bytes)...\n, size);
+ debug([BOOTP] Checking extension (%d bytes)...\n, size);
while ((ext end) (*ext != 0xff)) {
if (*ext == 0) {
@@ -269,34 +258,27 @@ static void BootpVendorProcess (u8 * ext, int size)
}
}
-#ifdef DEBUG_BOOTP_EXT
- puts ([BOOTP] Received fields: \n);
+ debug([BOOTP] Received fields: \n);
if (NetOurSubnetMask)
- printf (NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
+ debug(NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
if (NetOurGatewayIP)
- printf (NetOurGatewayIP: %pI4, NetOurGatewayIP);
+ debug(NetOurGatewayIP : %pI4, NetOurGatewayIP);
- if (NetBootFileSize) {
- printf (NetBootFileSize : %d\n, NetBootFileSize);
- }
+ if (NetBootFileSize)
+ debug(NetBootFileSize : %d\n, NetBootFileSize);
- if (NetOurHostName[0]) {
- printf (NetOurHostName : %s\n, NetOurHostName);
- }
+ if (NetOurHostName[0])
+ debug(NetOurHostName : %s\n, NetOurHostName);
- if (NetOurRootPath[0]) {
- printf (NetOurRootPath : %s\n, NetOurRootPath);
- }
+ if (NetOurRootPath[0])
+ debug(NetOurRootPath : %s\n, NetOurRootPath);
- if (NetOurNISDomain[0]) {
- printf (NetOurNISDomain : %s\n, NetOurNISDomain);
- }
+ if (NetOurNISDomain[0])
+ debug(NetOurNISDomain : %s\n, NetOurNISDomain);
- if (NetBootFileSize) {
- printf (NetBootFileSize: %d\n, NetBootFileSize);
- }
-#endif /* DEBUG_BOOTP_EXT */
+ if (NetBootFileSize)
+ debug(NetBootFileSize: %d\n, NetBootFileSize);
}
/*
* Handle a BOOTP received packet.
@@ -307,7 +289,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned src,
unsigned len
Re: [U-Boot] http client?
On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us? Yes - Although it sounds like your schedule is more immediate than mine... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Less verbose output when loading vxworks 6.x images
On Wed 22 Jul 2009 15:32, Niklaus Giger pondered:
Loading vxWorks 5.x images resulted just into 3 or 4 lines of output.
With vxWorks 6.x and the new GCC it emits about 30 lines, which is
far too noisy in my opinion.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
common/cmd_elf.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index abec7dd..0842ce9 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -286,6 +286,7 @@ unsigned long load_elf_image (unsigned long addr)
continue;
}
+#ifdef DEBUG
if (strtab) {
printf (%sing %s @ 0x%08lx (%ld bytes)\n,
(shdr-sh_type == SHT_NOBITS) ?
@@ -294,6 +295,7 @@ unsigned long load_elf_image (unsigned long addr)
(unsigned long) shdr-sh_addr,
(long) shdr-sh_size);
}
+#endif
if (shdr-sh_type == SHT_NOBITS) {
memset ((void *)shdr-sh_addr, 0,
shdr-sh_size);
its better to remove the ifdef, and replace the printf() with debug() (IMHO).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:32, Ben Warren pondered: Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:53, Ben Warren pondered: Robin Getz wrote: I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think). Is this not good enough? When I looked at the RFC data blocksize no gateway with gateway - -- 51223.85 37.05 102416.15 25.65 143213.70 23.10 204810.90 16.90 4096 6.85 9.65 8192 4.90 6.15 it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 18:00, Alessandro Rubini pondered:
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly (which
does add overhead as the number of gateways increases) may be worth
the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds,
4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then make
a decision.
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] minor debug cleanups in ./net
From: Robin Getz rg...@blackfin.uclinux.org
Minor ./net cleanups - no functional changes
- change #ifdef DEBUG printf(); #endif to just debug()
- changed __FUNCTION__ to __func__
- got rid of extra whitespace between function and opening brace
- removed unnecessary braces on if statements
gcc dead code elimination should make this functionally/size equivalent
when DEBUG is not defined. (confirmed on Blackfin, with gcc 4.3.3).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
Most changes are:
-#ifdef DEBUG
- printf(packet received\n);
-#endif
+ debug(packet received\n);
which is just plain nicer to read...
Makefile |2 -
bootp.c | 81 ++---
eth.c|8 ++---
net.c| 78 ---
nfs.c| 42 ++-
rarp.c |4 --
sntp.c |6 +--
tftp.c | 21 +++--
8 files changed, 78 insertions(+), 164 deletions(-)
---
diff --git a/net/Makefile b/net/Makefile
index 835a04a..ff87d87 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,7 +23,7 @@
include $(TOPDIR)/config.mk
-# CFLAGS += -DET_DEBUG -DDEBUG
+# CFLAGS += -DDEBUG
LIB= $(obj)libnet.a
diff --git a/net/bootp.c b/net/bootp.c
index d5f9c4b..0799ae2 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -8,17 +8,6 @@
* Copyright 2000-2004 Wolfgang Denk, w...@denx.de
*/
-#if 0
-#define DEBUG 1 /* general debug */
-#define DEBUG_BOOTP_EXT 1 /* Debug received vendor fields */
-#endif
-
-#ifdef DEBUG_BOOTP_EXT
-#define debug_ext(fmt,args...) printf (fmt ,##args)
-#else
-#define debug_ext(fmt,args...)
-#endif
-
#include common.h
#include command.h
#include net.h
@@ -107,7 +96,7 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned
src, unsigned len)
retval = -6;
}
- debug (Filtering pkt = %d\n, retval);
+ debug(Filtering pkt = %d\n, retval);
return retval;
}
@@ -129,7 +118,7 @@ static void BootpCopyNetParams(Bootp_t *bp)
if (strlen(bp-bp_file) 0)
copy_filename (BootFile, bp-bp_file, sizeof(BootFile));
- debug (Bootfile: %s\n, BootFile);
+ debug(Bootfile: %s\n, BootFile);
/* Propagate to environment:
* don't delete exising entry when BOOTP / DHCP reply does
@@ -156,7 +145,7 @@ static void BootpVendorFieldProcess (u8 * ext)
{
int size = *(ext + 1);
- debug_ext ([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
+ debug([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
*(ext + 1));
NetBootFileSize = 0;
@@ -255,7 +244,7 @@ static void BootpVendorProcess (u8 * ext, int size)
{
u8 *end = ext + size;
- debug_ext ([BOOTP] Checking extension (%d bytes)...\n, size);
+ debug([BOOTP] Checking extension (%d bytes)...\n, size);
while ((ext end) (*ext != 0xff)) {
if (*ext == 0) {
@@ -269,34 +258,27 @@ static void BootpVendorProcess (u8 * ext, int size)
}
}
-#ifdef DEBUG_BOOTP_EXT
- puts ([BOOTP] Received fields: \n);
+ debug([BOOTP] Received fields: \n);
if (NetOurSubnetMask)
- printf (NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
+ debug(NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
if (NetOurGatewayIP)
- printf (NetOurGatewayIP: %pI4, NetOurGatewayIP);
+ debug(NetOurGatewayIP : %pI4, NetOurGatewayIP);
- if (NetBootFileSize) {
- printf (NetBootFileSize : %d\n, NetBootFileSize);
- }
+ if (NetBootFileSize)
+ debug(NetBootFileSize : %d\n, NetBootFileSize);
- if (NetOurHostName[0]) {
- printf (NetOurHostName : %s\n, NetOurHostName);
- }
+ if (NetOurHostName[0])
+ debug(NetOurHostName : %s\n, NetOurHostName);
- if (NetOurRootPath[0]) {
- printf (NetOurRootPath : %s\n, NetOurRootPath);
- }
+ if (NetOurRootPath[0])
+ debug(NetOurRootPath : %s\n, NetOurRootPath);
- if (NetOurNISDomain[0]) {
- printf (NetOurNISDomain : %s\n, NetOurNISDomain);
- }
+ if (NetOurNISDomain[0])
+ debug(NetOurNISDomain : %s\n, NetOurNISDomain);
- if (NetBootFileSize) {
- printf (NetBootFileSize: %d\n, NetBootFileSize);
- }
-#endif /* DEBUG_BOOTP_EXT */
+ if (NetBootFileSize)
+ debug(NetBootFileSize: %d\n, NetBootFileSize);
}
/*
* Handle a BOOTP received packet.
@@ -307,7 +289,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned src,
unsigned len)
Bootp_t *bp;
char*s;
- debug (got BOOTP packet (src=%d, dst=%d, len=%d want_len=%zu)\n,
+ debug(got BOOTP packet (src=%d, dst=%d, len=%d want_len=%zu)\n,
src, dest, len, sizeof (Bootp_t));
bp
Re: [U-Boot] [RFC] CONFIG naming convetion
On Mon 20 Jul 2009 16:33, Wolfgang Denk pondered: Dear Robin Getz, [snip] You seem to live on a different planet than me. That is a well though out point. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - save the server's mac address...
On Tue 21 Jul 2009 02:37, Ben Warren pondered:
Can you please re-submit using git tools?
From: Robin Getz rg...@blackfin.uclinux.org
Linux's netconsole works much better when you can pass it the MAC address of
the server. (otherwise it just uses broadcast, which everyone else on my
network complains about :)
This sets the env var serveraddr (to match ethaddr), so that you can pass
it to linux with whatever bootargs you want to
addnetconsole=set bootargs $(bootargs)
netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
Signed-of-by: Robin Getz rg...@blackfin.uclinux.org
-
diff --git a/README b/README
index 4c74cb7..9071472 100644
--- a/README
+++ b/README
@@ -1184,6 +1184,11 @@ The following options need to be configured:
Defines a default value for the IP address of a TFTP
server to contact when using the tftboot command.
+ CONFIG_KEEP_SERVERADDR
+
+ Keeps the server's MAC address, in the env 'serveraddr'
+ for passing to bootargs (like Linux's netconsole option)
+
- Multicast TFTP Mode:
CONFIG_MCAST_TFTP
diff --git a/net/net.c b/net/net.c
index 7ce947d..641c37c 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1287,6 +1287,15 @@ NetReceive(volatile uchar * inpkt, int len)
/* are we waiting for a reply */
if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC)
break;
+
+#ifdef CONFIG_KEEP_SERVERADDR
+ if (NetServerIP == NetArpWaitPacketIP) {
+ char buf[20];
+ sprintf(buf, %pM, arp-ar_data);
+ setenv(serveraddr, buf);
+ }
+#endif
+
#ifdef ET_DEBUG
printf(Got ARP REPLY, set server/gtwy eth addr
(%pM)\n,
arp-ar_data);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Sorry - first time I sent this -- I forgot to cc the list... On Tue 21 Jul 2009 12:37, Robin Getz pondered: redboot supports (and has since 2002) a mini-http client: This is just a transfer data via the network using HTTP protocol, no better or worse than tftp. (no https, no proxy, no other protocols). http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/redboot/current/src/net/http_client.c?rev=1.11content-type=text/x-cvsweb-markupcvsroot=ecos I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. If a port of the redboot functionality is done - any thoughts on if it would be accepted? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] v3 - add dns
On 04 Oct 2008 Pieter posted a dns implementation for U-Boot.
http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg10216.html
DNS can be enabled by setting CFG_CMD_DNS. After performing a query,
the serverip environment var is updated.
Probably there are some cosmetic issues with the patch. Unfortunatly I
do not have the time to correct these. So if anybody else likes DNS
support in U-Boot and has the time, feel free to patch it in the main tree.
Here it is again - slightly modified smaller:
- update to 2009-06 (Pieter's patch was for U-Boot 1.2.0)
- README.dns is added
- syntax is changed (now takes a third option, the env var to store
the result in)
- add a random port() function in net.c
- sort Makefile in ./net/Makefile
- dns just returns unless a env var is given
- run through checkpatch, and clean up style issues
- remove packet from stack
- cleaned up some comments
- failure returns much faster (if server responds, don't wait for
timeout)
- use built in functions (memcpy) rather than byte copy.
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
Signed-off-by: Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
common/cmd_net.c | 49 ++
doc/README.dns | 64 +
include/net.h|5 +
net/Makefile |7 -
net/dns.c| 211 +
net/dns.h| 39
net/net.c| 29 ++
7 files changed, 401 insertions(+), 3 deletions(-)
---
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 68183c4..ac706ae 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -353,3 +353,52 @@ U_BOOT_CMD(
[NTP server IP]\n
);
#endif
+
+#if defined(CONFIG_CMD_DNS)
+int do_dns(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ if (argc == 1) {
+ cmd_usage(cmdtp);
+ return -1;
+ }
+
+ /*
+* We should check for a valid hostname:
+* - Each label must be between 1 and 63 characters long
+* - the entire hostname has a maximum of 255 characters
+* - only the ASCII letters 'a' through 'z' (case-insensitive),
+* the digits '0' through '9', and the hyphen
+* - cannot begin or end with a hyphen
+* - no other symbols, punctuation characters, or blank spaces are
+* permitted
+* but hey - this is a minimalist implmentation, so only check length
+* and let the name server deal with things.
+*/
+ if (strlen(argv[1]) = 255) {
+ printf(dns error: hostname too long\n);
+ return 1;
+ }
+
+ NetDNSResolve = argv[1];
+
+ if (argc == 3)
+ NetDNSenvvar = argv[2];
+ else
+ NetDNSenvvar = NULL;
+
+ if (NetLoop(DNS) 0) {
+ printf(dns lookup of %s failed, check setup\n, argv[1]);
+ return 1;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ dns,3, 1, do_dns,
+ lookup the IP of a hostname,
+ hostname [envvar]
+);
+
+#endif /* CONFIG_CMD_DNS */
+
diff --git a/doc/README.dns b/doc/README.dns
new file mode 100644
index 000..deeccd7
--- /dev/null
+++ b/doc/README.dns
@@ -0,0 +1,64 @@
+Domain Name System
+---
+
+The Domain Name System (DNS) is a hierarchical naming system for computers,
+services, or any resource participating in the Internet. It associates various
+information with domain names assigned to each of the participants. Most
+importantly, it translates domain names meaningful to humans into the numerical
+(binary) identifiers associated with networking equipment for the purpose of
+locating and addressing these devices world-wide. An often used analogy to
+explain the Domain Name System is that it serves as the phone book for the
+Internet by translating human-friendly computer hostnames into IP addresses.
+For example, www.example.com translates to 208.77.188.166.
+
+For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
+
+
+
+U-Boot and DNS
+--
+
+CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
+ will send name lookups to the dns server (env var 'dnsip')
+ Turning this option on will about abou 1k to U-Boot's size.
+
+ Example:
+
+bfin print dnsip
+dnsip=192.168.0.1
+
+bfin dns www.google.com
+66.102.1.104
+
+ By default, dns does nothing except print the IP number on
+ the default console - which by itself, would be pretty
+ useless. Adding a third argument to the dns command will
+ use that as the environment variable to be set.
+
+ Example:
+
+bfin print googleip
+## Error: googleip not defined
+bfin dns www.google.com googleip
+64.233.161.104
+bfin print googleip
+googleip=64.233.161.104
+bfin ping ${googleip}
+Using
Re: [U-Boot] [PATCH] - add dns
On Sun 19 Jul 2009 03:48, Wolfgang Denk pondered: Dear Robin Getz, In message 200907172120.50413.rg...@blackfin.uclinux.org you wrote: On Fri 17 Jul 2009 16:55, Wolfgang Denk pondered: Please keep list sorted. sorted how? What we have today is: COBJS-y += net.o COBJS-y += tftp.o COBJS-y += bootp.o COBJS-y += rarp.o COBJS-y += eth.o COBJS-y += nfs.o COBJS-$(CONFIG_CMD_SNTP) += sntp.o It is not sorted alphabetically... ??? I see. Sorry. Well, please use the opportunity to sort that list, then. Alphabetically. Ok -- what I have is this then. I'll wrap it up tomorrow and send to Ben, assuming he doesn't have anything else... diff --git a/net/Makefile b/net/Makefile index d341874..835a04a 100644 --- a/net/Makefile +++ b/net/Makefile @@ -27,13 +27,14 @@ include $(TOPDIR)/config.mk LIB= $(obj)libnet.a -COBJS-y += net.o -COBJS-y += tftp.o COBJS-y += bootp.o -COBJS-y += rarp.o +COBJS-$(CONFIG_CMD_DNS) += dns.o COBJS-y += eth.o +COBJS-y += net.o COBJS-y += nfs.o +COBJS-y += rarp.o COBJS-$(CONFIG_CMD_SNTP) += sntp.o +COBJS-y += tftp.o COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Sat 18 Jul 2009 21:15, Mike Frysinger pondered: On Saturday 18 July 2009 20:27:00 Robin Getz wrote: On Sat 18 Jul 2009 18:11, Mike Frysinger pondered: keep the modulus something with only 1 bit set so gcc will optimize into a simple and operation. probably add a comment about it too: /* make src port a little random, but use something trivial to compute */ OK - So, this would give three different variations: So, these are definitality ugly... net/tftp.c: TftpOurPort = 1024 + (get_timer(0) % 3072); _random_port: 0: 78 05 [--SP] = (R7:7); 2: 67 01 [--SP] = RETS; 4: a6 6f SP += -0xc; /* (-12) */ 6: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 8: ff e3 fc ff CALL 0x0 _random_port; a: R_BFIN_PCREL24 _get_timer c: 41 e1 aa aa R1.H = 0x; /* (-21846) R1=0x000c(-1431699444) */ 10: 01 e1 ab aa R1.L = 0xaaab; /* (-21845) R1=0xaaab(-1431655765) */ 14: 38 30 R7 = R0; 16: ff e3 f5 ff CALL 0x0 _random_port; 18: R_BFIN_PCREL24 ___umulsi3_highpart 1a: 58 4e R0 = 0xb; 1c: 21 e1 00 0c R1 = 0xc00 (X); /* R1=0xc00(3072) */ 20: c8 40 R0 *= R1; 22: 66 6c SP += 0xc; /* ( 12) */ 24: c7 53 R7 = R7 - R0; 26: 20 e1 00 04 R0 = 0x400 (X); /* R0=0x400(1024) */ 2a: c7 51 R7 = R7 + R0; 2c: 27 01 RETS = [SP++]; 2e: 07 30 R0 = R7; 30: 38 05 (R7:7) = [SP++]; 32: 10 00 RTS; Disassembly of section .text.NetSetTimeout: net/nfs.c: NfsOurPort = 4096 + (get_ticks() % 3072); _random_port: 0: 67 01 [--SP] = RETS; 2: 86 6f SP += -0x10;/* (-16) */ 4: ff e3 fe ff CALL 0x0 _random_port; 6: R_BFIN_PCREL24 _get_ticks 8: 02 60 R2 = 0x0 (X); /* R2=0x0( 0) */ a: f2 b0 [SP + 0xc] = R2; c: 22 e1 00 0c R2 = 0xc00 (X); /* R2=0xc00(3072) */ 10: ff e3 f8 ff CALL 0x0 _random_port; 12: R_BFIN_PCREL24 ___umoddi3 14: 86 6c SP += 0x10; /* ( 16) */ 16: 08 30 R1 = R0; 18: 27 01 RETS = [SP++]; 1a: 20 e1 00 10 R0 = 0x1000 (X);/* R0=0x1000(4096) */ 1e: 01 50 R0 = R1 + R0; 20: 10 00 RTS; net/sntp.c: SntpOurPort = 1 + (get_timer(0) % 4096); _random_port: 0: 67 01 [--SP] = RETS; 2: a6 6f SP += -0xc; /* (-12) */ 4: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 6: ff e3 fd ff CALL 0x0 _random_port; 8: R_BFIN_PCREL24 _get_timer a: 21 e1 ff 0f R1 = 0xfff (X); /* R1=0xfff(4095) */ e: 66 6c SP += 0xc; /* ( 12) */ 10: 08 54 R0 = R0 R1; 12: 27 01 RETS = [SP++]; 14: 21 e1 10 27 R1 = 0x2710 (X);/* R1=0x2710(1) */ 18: 08 50 R0 = R0 + R1; 1a: 10 00 RTS; Disassembly of section .text.NetSetTimeout: 1024 + (get_timer(0) % 0x8000); _random_port: 0: 67 01 [--SP] = RETS; 2: a6 6f SP += -0xc; /* (-12) */ 4: 00 60 R0 = 0x0 (X); /* R0=0x0( 0) */ 6: ff e3 fd ff CALL 0x0 _random_port; 8: R_BFIN_PCREL24 _get_timer a: 21 e1 ff 7f R1 = 0x7fff (X);/* R1=0x7fff(32767) */ e: 66 6c SP += 0xc; /* ( 12) */ 10: 08 54 R0 = R0 R1; 12: 27 01 RETS = [SP++]; 14: 21 e1 00 04 R1 = 0x400 (X); /* R1=0x400(1024) */ 18: 08 50 R0 = R0 + R1; 1a: 10 00 RTS; Disassembly of section .text.NetSetTimeout: Does it make sense to have 4 different ones? (not to me)... Or something new common in ./net.c:random_port() i would make a new patch that adds a new random_port() function and converts existing consumers to that, and then have the dns code rely on that. and you should adopt my implementation because the generated code is much much nicer than the others ;) At least on Blackfin - the sntp version and yours are computationally equal - although I think yours ends up being more random - so yeah, I'll use that one. a quick google shows: - sntp - any non-zero source port is OK - tftp - between 0 and 65535 - nfs - couldnt find anything, but i'm pretty sure there isnt one get_ticks() and get_timer(0) are pretty much equivalent Sounds
Re: [U-Boot] [RFC] CONFIG naming convetion
On Sat 18 Jul 2009 18:25, Wolfgang Denk pondered: I guess we could back up a step and look at the users, and defined things as things that should be changed by: - arch maintainers (Core/CPU specific) - SoC maintainer (SoC specific) - Board maintainer (PCB specific) - End user of the above (changes options, but nothing from the above list?) Frankly, this makes no sense to me. I have yet to see any such clear split of roles and functions. When you bring up a new board, you usually have to check everything. The only split that made, and still makes, kind of sense to me is the split into normal users (CONFIG_) versus root (CONFIG_SYS_) groups. I guess I still don't understand how you are making the distinction between normal users and root - I think there are more categories of users between those two... People responsible for the archicture/CPU core may set things up, and not want anyone to change things - on any SoC or Board. People responsible for SoC developments should be able to take what the arch provider delivers, write a few device drivers, make some specific choices that anyone who implements that SoC is going to have to live with. People responsible for Board porting, should be able to take what the SoC provider delivers, customise things for their platform, and move on. Then there are end users - which must live with the choices that all three have made, until they get their own hardware back, or in the case where the hardware is a module - just change some non-hardware related options. So maybe it is core, chip, PCB, and user. In some cases - all 4 categories are the same person - in many cases they are not. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] CONFIG naming convetion
On Sat 18 Jul 2009 07:03, Jean-Christophe PLAGNIOL-VILLARD pondered: Hi all, Currently we have a mess in the drivers CONFIG naming convention as example on I2C we have CONFIG_I2C_X CONFIG_DRIVER_XXX_I2C CONFIG__I2C CONFIG_SYS_I2C_ I think it will good to have common and clean naming convention so I'll propose we use this one CONFIG_namespace_X and CONFIG_SYS_namespace_X so it will resutly for I2C to this CONFIG_I2C_X CONFIG_SYS_I2C_ and the Makefile and KConfig it will be easier to sort and read I think this goes way beyond I2C There are ~4866 unique options in ./include/configs/* Most of which have no name spaces at all, some are not even used in any source files (that are in mainline anyway). We have 2815, which already start with CONFIG_SYS_xxx, like CONFIG_SYS_16M_MBMR Which is used in a single board: board/snmc/qs860t/qs860t.c: memctl-memc_mbmr = CONFIG_SYS_16M_MBMR; board/snmc/qs860t/qs860t.c: size = dram_size (CONFIG_SYS_16M_MBMR, (long *)SDRAM_BASE, SDRAM_16M_MAX_SIZE); include/configs/QS860T.h:#define CONFIG_SYS_16M_MBMR0x18802114 /* Mem Periodic Timer Prescaler */ It doesn't appear very system oriented to me... It would be nice to come up with some list of namespaces, and what they they should be used for... For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX Again - which is only used in one place: drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C Which is fine - since it is a driver, which I'm sure that people out of tree use. we assumed that it was: CONFIG_DRIVER_NAND_BFIN but it depends on who added it... CONFIG_PATA_BFIN drivers/block/Makefile:COBJS-$(CONFIG_PATA_BFIN) += pata_bfin.o include/configs/bf548-ezkit.h:#define CONFIG_PATA_BFIN I would think should be CONFIG_DRIVERS_PATA_BFIN ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] CONFIG naming convetion
On Sat 18 Jul 2009 13:50, Wolfgang Denk pondered: Dear Robin Getz, In message 200907181115.26404.rg...@blackfin.uclinux.org you wrote: It would be nice to come up with some list of namespaces, and what they they should be used for... Agreed. Excellent - a common goal :) For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined. And the DRIVER_ part makes not much sense to me in any of the examples above. It's a namespace - controls if a driver is compile in or not. Should only be used in .config files, and Makefiles. Some (very few) already use it.. ./drivers/serial/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_CS8900) += cs8900.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_DM9000) += dm9000x.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NETARMETH) += netarm_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS7520_ETHERNET) += ns7520_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC9) += smc9.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o ./drivers/mtd/Makefile:COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o ./drivers/mtd/nand/Makefile:COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o ./board/micronas/vct/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += ebi_smc911x.o smc_eeprom.o ./cpu/arm926ejs/davinci/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o My personal way of thinking about such options is usually CPU/archi- tecture first, so I would probably chose CONFIG_OMAP24XX_I2C to en- able/disable the I2C driver on a OMAP24XX based board, but I under- stand that there are reasons to prefer CONFIG_I2C_OMAP24XX as well - let's see if there is a clear majority of opiniions... If we are thinking of a tree type structure - it might make sense to start at the top? I guess the question is -- is it an I2C driver for the OMAP24xx or a OMAP24xx driver for I2C? Since the API is a I2C API - my thought it is an I2C driver, which happens to run on a specific SoC. The actual SoC doesn't really matter (and should be last) - so it is similar to the directory structure we have today. Again - which is only used in one place: drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C Which is fine - since it is a driver, which I'm sure that people out of tree use. Well, if only out-of-tree ports use it, it probably should never have been added in the first place. Then I can start sending patches for unused CONFIG_ from random config files, and no one will start complaining? From what I can quickly tell - there seems to be about 472 different CONFIG_ options in ./include/config that are not actually used anywhere in the master tree. I would think should be CONFIG_DRIVERS_PATA_BFIN I dosagree, the DRIVERS part is just added line noise. It's a name space - making sure it is differentiated from an option. As you pointed out - this is what exists in the README today. (which I have read, but gained no clarity from it)... === * Configuration _OPTIONS_: These are selectable by the user and have names beginning with CONFIG_. * Configuration _SETTINGS_: These depend on the hardware etc. and should not be meddled with if you don't know what you're doing; they have names beginning with CONFIG_SYS_. === I think there needs to be more words - do you mean: - hardware, CPU level? or - hardware, SoC level? or - hardware, board level? Personally - I don't think board level things should be CONFIG_SYS_, as these need to be switched around by board porters. I guess we could back up a step and look
Re: [U-Boot] [RFC] CONFIG naming convetion
On Sat 18 Jul 2009 11:52, Jean-Christophe PLAGNIOL-VILLARD pondered: On 11:15 Sat 18 Jul , Robin Getz wrote: It doesn't appear very system oriented to me... it's as we had reorganise the drivers file place as example or the common Makefile and continue to do it eveyday (take a look on Peter e-mail about arch dir) It would be nice to come up with some list of namespaces, and what they they should be used for... For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX DRIVER is really un-nessary IMHO It doesn't cost extra $ to keep 6 letters - and makes it alot more clear about what it does. I understand the point about having really _long_ names, and personally think things like ThisVariableIsATemporaryCounter are brain dead, but I don't think we have hit that yet with CONFIG_ yet. We already have lots (419) that are over 30 chars, and some over 40! 40 CONFIG_SYS_TFTP_BLINK_STATUS_ON_DATA_IN 41 CONFIG_SYS_MONAHANS_TURBO_RUN_MODE_RATIO 41 CONFIG_SYS_MPC8220_SYSPLL_VCO_MULTIPLIER 42 CONFIG_SYS_PCI_SUBSYS_DEVICEID_NONMONARCH ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - save the server's mac address...
On Thu 16 Jul 2009 12:56, Ben Warren pondered: Mike Frysinger wrote: On Monday 13 July 2009 16:19:51 Robin Getz wrote: + CONFIG_KEEP_SERVERADDR + + Keeps the server's MAC address, in the env 'serveraddr' + for passing to bootargs (like Linux's netconsole option) is a config option really necessary ? i'd say just add it for everyone -mike ACK Does that mean you want a new patch with the ifdef removed? -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] - add dns
On 04 Oct 2008 Pieter posted a dns implementation for U-Boot.
http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg10216.html
DNS can be enabled by setting CFG_CMD_DNS. After performing a query, the
serverip environment var is updated.
Probably there are some cosmetic issues with the patch. Unfortunatly I do
not have the time to correct these. So if anybody else likes DNS support in
U-Boot and has the time, feel free to patch it in the main tree.
Here it is again - slightly modified smaller:
- update to 2009-06 (Pieter's patch was for U-Boot 1.2.0)
- run through checkpatch, and clean up style issues
- remove packet from stack
- cleaned up some comments
- failure returns much faster (if server responds, don't wait for timeout)
- use built in functions (memcpy) rather than byte copy.
bfin dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.0.4
bfin dns pool.ntp.org
69.36.241.112
bfin sntp $(serverip)
Date: 2009-07-17 Time: 19:16:51
bfin dns www.google.com
64.233.161.147
bfin ping $(serverip)
Using Blackfin EMAC device
host 64.233.161.147 is alive
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
Signed-off-by: Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
common/cmd_net.c | 32
include/configs/bfin_adi_common.h |7
include/net.h |4
net/Makefile |1
net/dns.c | 213
net/dns.h | 38
net/net.c | 20 ++
7 files changed, 314 insertions(+), 1 deletion(-)
---
Index: include/net.h
===
--- include/net.h (revision 1968)
+++ include/net.h (working copy)
@@ -361,6 +361,10 @@
/* from net/net.c */
extern charBootFile[128]; /* Boot File name
*/
+#if defined(CONFIG_CMD_DNS)
+extern char NetDNSResolve[255];/* The host to resolve
*/
+#endif
+
#if defined(CONFIG_CMD_PING)
extern IPaddr_tNetPingIP; /* the ip address to
ping */
#endif
Index: include/configs/bfin_adi_common.h
===
--- include/configs/bfin_adi_common.h (revision 1968)
+++ include/configs/bfin_adi_common.h (working copy)
@@ -13,6 +13,13 @@
# if ADI_CMDS_NETWORK
# define CONFIG_CMD_DHCP
# define CONFIG_CMD_PING
+# define CONFIG_BOOTP_DNS
+# define CONFIG_BOOTP_DNS2
+# define CONFIG_CMD_DNS
+# ifdef CONFIG_RTC_BFIN
+# define CONFIG_CMD_SNTP
+# define CONFIG_BOOTP_NTPSERVER
+# endif
# ifdef CONFIG_BFIN_MAC
# define CONFIG_CMD_MII
# endif
Index: net/dns.c
===
--- net/dns.c (revision 0)
+++ net/dns.c (revision 0)
@@ -0,0 +1,213 @@
+/*
+ * DNS support driver
+ *
+ * Copyright (c) 2008 Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
+ * Copyright (c) 2009 Robin Getz rg...@blackfin.uclinux.org
+ *
+ * This is a simple DNS implementation for U-Boot. It will use the first IP
+ * in the DNS response as NetServerIP. This can then be used for any other
+ * network related activities.
+ *
+ * The packet handling is partly based on TADNS, original copyrights
+ * follow below.
+ *
+ */
+
+/*
+ * Copyright (c) 2004-2005 Sergey Lyubka vale...@gmail.com
+ *
+ * THE BEER-WARE LICENSE (Revision 42):
+ * Sergey Lyubka wrote this file. As long as you retain this notice you
+ * can do whatever you want with this stuff. If we meet some day, and you think
+ * this stuff is worth it, you can buy me a beer in return.
+ */
+
+#include common.h
+#include command.h
+#include net.h
+
+#include dns.h
+
+char NetDNSResolve[255]; /* The host to resolve */
+
+static int DnsOurPort;
+
+static void
+DnsSend(void)
+{
+ struct header *header;
+ int n, name_len;
+ uchar *p, *pkt;
+ const char *s;
+ const char *name;
+ enum dns_query_type qtype = DNS_A_RECORD;
+
+ name = NetDNSResolve;
+ pkt = p = (uchar *)(NetTxPacket + NetEthHdrSize() + IP_HDR_SIZE);
+
+ /* Prepare DNS packet header */
+ header = (struct header *) pkt;
+ header-tid = 1;
+ header-flags= htons(0x100);/* standard query */
+ header-nqueries = htons(1);/* Just one query */
+ header-nanswers = 0;
+ header-nauth= 0;
+ header-nother = 0;
+
+ /* Encode DNS name */
+ name_len = strlen(name);
+ p = (uchar *) header-data;/* For encoding host name into packet */
+
+ do {
+ s = strchr(name, '.');
+ if (!s)
+ s = name + name_len;
+
+ n = s - name; /* Chunk length */
+ *p++ = n; /* Copy length */
+ memcpy(p, name, n); /* Copy chunk
Re: [U-Boot] [PATCH] - add dns
On Fri 17 Jul 2009 16:55, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200907171553.08108.rg...@blackfin.uclinux.org you wrote:
On 04 Oct 2008 Pieter posted a dns implementation for U-Boot.
http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg10216.html
DNS can be enabled by setting CFG_CMD_DNS. After performing a query, the
serverip environment var is updated.
Probably there are some cosmetic issues with the patch. Unfortunatly I do
not have the time to correct these. So if anybody else likes DNS support
in
U-Boot and has the time, feel free to patch it in the main tree.
Here it is again - slightly modified smaller:
- update to 2009-06 (Pieter's patch was for U-Boot 1.2.0)
- run through checkpatch, and clean up style issues
- remove packet from stack
- cleaned up some comments
- failure returns much faster (if server responds, don't wait for timeout)
- use built in functions (memcpy) rather than byte copy.
bfin dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.0.4
bfin dns pool.ntp.org
69.36.241.112
bfin sntp $(serverip)
Date: 2009-07-17 Time: 19:16:51
bfin dns www.google.com
64.233.161.147
bfin ping $(serverip)
Using Blackfin EMAC device
host 64.233.161.147 is alive
Note that the use of $(...) is deprecated. Please use ${...}
instead,
OK.
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
Signed-off-by: Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
common/cmd_net.c | 32
include/configs/bfin_adi_common.h |7
include/net.h |4
net/Makefile |1
net/dns.c | 213
net/dns.h | 38
net/net.c | 20 ++
7 files changed, 314 insertions(+), 1 deletion(-)
You probably should add a doc/README.* file to explain how that is
supposed to be used.
Will do.
What is the rule for when things go in ./doc/README.* vs ./README ?
Index: include/net.h
===
--- include/net.h (revision 1968)
+++ include/net.h (working copy)
Could you generate a git patch instead?
Sure - I'll generate something from the net tree?
@@ -361,6 +361,10 @@
/* from net/net.c */
extern charBootFile[128]; /* Boot File name
*/
+#if defined(CONFIG_CMD_DNS)
+extern char NetDNSResolve[255];/* The host to resolve
*/
+#endif
Can this buffer overflow?
Shouldn't.
+ if (strlen(argv[1]) sizeof(NetDNSResolve) - 1) {
+ puts(Name too long.\n);
+ return -1;
+ }
+
Index: net/dns.c
===
--- net/dns.c (revision 0)
+++ net/dns.c (revision 0)
@@ -0,0 +1,213 @@
+/*
+ * DNS support driver
+ *
+ * Copyright (c) 2008 Pieter Voorthuijsen pieter.voorthuij...@prodrive.nl
+ * Copyright (c) 2009 Robin Getz rg...@blackfin.uclinux.org
+ *
+ * This is a simple DNS implementation for U-Boot. It will use the first IP
+ * in the DNS response as NetServerIP. This can then be used for any other
+ * network related activities.
Hmmm... why do you assume that the address we're trying to resolve is
the server IP?
To me it makes at least as much sense to resolve the ipaddr value.
Yeah, this was my biggest issue for things too (from the original patch).
but you can easily :
set nameip ${serverip}
to transfer it to something else. - or just use it directly.
Originally I thought about dnsip, but that pre-existing, and is used to store
the nameserver ip (which is poorly named IMHO).
any better suggestions welcome.
+char NetDNSResolve[255]; /* The host to resolve */
See above.
See answer :)
+static int DnsOurPort;
+
+static void
+DnsSend(void)
+{
...
+ do {
+ s = strchr(name, '.');
+ if (!s)
+ s = name + name_len;
+
+ n = s - name; /* Chunk length */
+ *p++ = n; /* Copy length */
+ memcpy(p, name, n); /* Copy chunk */
+ p += n;
+
+ if (*s == '.')
+ n++;
+
+ name += n;
+ name_len -= n;
+ } while (*s != '\0');
+
+ *p++ = 0; /* Mark end of host name */
+ *p++ = 0; /* Well, lets put this byte as well */
Why that?
No idea - that was in the original
Hmm -- according to my TCP/IP Illustrated - names are suppost to be double
null terminated - so I think that is a requirement.
+static void
+DnsHandler(uchar *pkt, unsigned dest, unsigned src, unsigned len)
+{
...
+ /* Received 0 answers */
+ if (header-nanswers == 0
Re: [U-Boot] [PATCH] - add dns
On Fri 17 Jul 2009 18:01, Wolfgang Denk pondered: Dear Robin Getz, In message 200907171745.36176.rg...@blackfin.uclinux.org you wrote: You probably should add a doc/README.* file to explain how that is supposed to be used. Will do. What is the rule for when things go in ./doc/README.* vs ./README ? Size - anything that takes more than 5...10 lines ? Could you generate a git patch instead? Sure - I'll generate something from the net tree? Please use the mainline repo / master branch as reference. Sure - but master's dhcp does not work for me until unassigned-patches/39 is applied. http://bugs.denx.de/databases/u-boot/prs/39 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Fri 17 Jul 2009 16:55, Wolfgang Denk pondered: Index: net/Makefile === --- net/Makefile(revision 1968) +++ net/Makefile(working copy) @@ -34,6 +34,7 @@ COBJS-y += eth.o COBJS-y += nfs.o COBJS-$(CONFIG_CMD_SNTP) += sntp.o +COBJS-$(CONFIG_CMD_DNS) += dns.o Please keep list sorted. sorted how? What we have today is: COBJS-y += net.o COBJS-y += tftp.o COBJS-y += bootp.o COBJS-y += rarp.o COBJS-y += eth.o COBJS-y += nfs.o COBJS-$(CONFIG_CMD_SNTP) += sntp.o It is not sorted alphabetically... ??? It's not sorted by length??? Seems to be sorted by date added, with the last ones on the bottom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - add dns
On Fri 17 Jul 2009 18:01, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200907171745.36176.rg...@blackfin.uclinux.org you wrote:
You probably should add a doc/README.* file to explain how that is
supposed to be used.
Will do.
What is the rule for when things go in ./doc/README.* vs ./README ?
Size - anything that takes more than 5...10 lines ?
Could you generate a git patch instead?
Sure - I'll generate something from the net tree?
Please use the mainline repo / master branch as reference.
v2 - based on mainline repo master
- implemented feedback from Wolfgang
common/cmd_net.c | 47
doc/README.dns| 64 +++
include/net.h |5
net/Makefile |1
net/dns.c | 212 ++
net/dns.h | 38 ++
net/net.c | 19 +++
8 files changed, 393 insertions(+)
---
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 68183c4..8899143 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -353,3 +353,50 @@ U_BOOT_CMD(
[NTP server IP]\n
);
#endif
+
+#if defined(CONFIG_CMD_DNS)
+int do_dns(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ if (argc == 1) {
+ cmd_usage(cmdtp);
+ return -1;
+ }
+
+ /*
+* We should check for a valid hostname:
+* - Each label must be between 1 and 63 characters long
+* - the entire hostname has a maximum of 255 characters
+* - only the ASCII letters 'a' through 'z' (case-insensitive),
+* the digits '0' through '9', and the hyphen
+* - cannot begin or end with a hyphen
+* - no other symbols, punctuation characters, or blank spaces are
permitted
+* but hey - this is a minimalist implmentation, so only check length
+*/
+ if (strlen(argv[1]) = 255) {
+ printf(dns error: hostname too long\n);
+ return 1;
+ }
+
+ NetDNSResolve = argv[1];
+
+ if (argc == 3)
+ NetDNSenvvar = argv[2];
+ else
+ NetDNSenvvar = NULL;
+
+ if (NetLoop(DNS) 0) {
+ printf(dns lookup of %s failed, check setup\n, argv[1]);
+ return 1;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ dns,3, 1, do_dns,
+ lookup the IP of a hostname,
+ hostname [envvar]
+);
+
+#endif /* CONFIG_CMD_DNS */
+
diff --git a/doc/README.dns b/doc/README.dns
new file mode 100644
index 000..deeccd7
--- /dev/null
+++ b/doc/README.dns
@@ -0,0 +1,64 @@
+Domain Name System
+---
+
+The Domain Name System (DNS) is a hierarchical naming system for computers,
+services, or any resource participating in the Internet. It associates various
+information with domain names assigned to each of the participants. Most
+importantly, it translates domain names meaningful to humans into the numerical
+(binary) identifiers associated with networking equipment for the purpose of
+locating and addressing these devices world-wide. An often used analogy to
+explain the Domain Name System is that it serves as the phone book for the
+Internet by translating human-friendly computer hostnames into IP addresses.
+For example, www.example.com translates to 208.77.188.166.
+
+For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
+
+
+
+U-Boot and DNS
+--
+
+CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
+ will send name lookups to the dns server (env var 'dnsip')
+ Turning this option on will about abou 1k to U-Boot's size.
+
+ Example:
+
+bfin print dnsip
+dnsip=192.168.0.1
+
+bfin dns www.google.com
+66.102.1.104
+
+ By default, dns does nothing except print the IP number on
+ the default console - which by itself, would be pretty
+ useless. Adding a third argument to the dns command will
+ use that as the environment variable to be set.
+
+ Example:
+
+bfin print googleip
+## Error: googleip not defined
+bfin dns www.google.com googleip
+64.233.161.104
+bfin print googleip
+googleip=64.233.161.104
+bfin ping ${googleip}
+Using Blackfin EMAC device
+host 64.233.161.104 is alive
+
+ In this way, you can lookup, and set many more meaningful
+ things.
+
+bfin sntp
+ntpserverip not set
+bfin dns pool.ntp.org ntpserverip
+72.18.205.156
+bfin sntp
+Date: 2009-07-18 Time: 4:06:57
+
+ For some helpful things that can be related to DNS in U-Boot,
+ look at the top level README for these config options:
+CONFIG_CMD_DHCP
+CONFIG_BOOTP_DNS
+CONFIG_BOOTP_DNS2
Re: [U-Boot] DHCP regression on 2009-06
On Mon 13 Jul 2009 11:11, Michael Zaidman pondered: I did verify that reverting the line exposes the bug that Michael fixed, ... Ok, my target uses static IP configuration so I did not verified the DHCP behavior. Now I did it. I also reverted the line and did DHCP afterwards changed the subnet and did DHCP again. It works as expected. diff --git a/net/net.c b/net/net.c index 5637cf5..5e43dd1 100644 --- a/net/net.c +++ b/net/net.c @@ -388,6 +388,7 @@ restart: #if defined(CONFIG_CMD_DHCP) case DHCP: BootpTry = 0; + NetOurIP = 0; DhcpRequest(); /* Basically same as BOOTP */ break; #endif OK - I tested it - and it seems to work for me. Some of my debugging crap when I was tracking this down must have messed this up. Ack-by: Robin Getz rg...@blackfin.uclinux.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] - save the server's mac address...
From: Robin Getz rg...@blackfin.uclinux.org
Linux's netconsole works much better when you can pass it the MAC address of
the server. (otherwise it just uses broadcast, which everyone else on my
network complains about :)
This sets the env var serveraddr (to match ethaddr), so that you can pass
it to linux with whatever bootargs you want to
addnetconsole=set bootargs $(bootargs)
netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
Signed-of-by: Robin Getz rg...@blackfin.uclinux.org
---
Index: net/net.c
===
--- net/net.c (revision 1968)
+++ net/net.c (working copy)
@@ -1273,6 +1274,15 @@
/* are we waiting for a reply */
if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC)
break;
+
+#ifdef CONFIG_KEEP_SERVERADDR
+ if (NetServerIP == NetArpWaitPacketIP) {
+ char buf[20];
+ sprintf(buf, %pM, arp-ar_data);
+ setenv(serveraddr, buf);
+ }
+#endif
+
#ifdef ET_DEBUG
printf(Got ARP REPLY, set server/gtwy eth addr
(%pM)\n,
arp-ar_data);
Index: README
===
--- README (revision 1968)
+++ README (working copy)
@@ -1165,6 +1165,11 @@
Defines a default value for the IP address of a TFTP
server to contact when using the tftboot command.
+ CONFIG_KEEP_SERVERADDR
+
+ Keeps the server's MAC address, in the env 'serveraddr'
+ for passing to bootargs (like Linux's netconsole option)
+
- Multicast TFTP Mode:
CONFIG_MCAST_TFTP
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DHCP regression on 2009-06
On Sun 12 Jul 2009 09:14, Michael Zaidman pondered:
On Fri, Jul 10, 2009 at 10:18 PM, Robin Getz rg...@blackfin.uclinux.org
wrote:
On Fri 10 Jul 2009 12:27, Robin Getz pondered:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5858fae38478d6399be4a16be3fc
causes a regression on my network's DHCP server.
The part of the diff that causes the problem:
#if defined(CONFIG_CMD_DHCP)
case DHCP:
- /* Start with a clean slate... */
BootpTry = 0;
- NetOurIP = 0;
- NetServerIP = getenv_IPaddr (serverip);
DhcpRequest(); /* Basically same as BOOTP */
break;
Since we are leaving the NetOurIP to whatever it was... The test at:
NetReceive():
case PROT_IP:
[snip]
tmp = NetReadIP(ip-ip_dst);
if (NetOurIP tmp != NetOurIP tmp != 0x) {
return;
}
Will return - (we leave the 'NetOurIP' set to the old value, the offered
address (what is in tmp) is not our's and tmp is not 0x).
You never process the DHCP_OFFER...
Did you try to remove the CONFIG_IPADDR from the board's config file?
In this case the NetOurIP will get 0. That should solve the problem.
No it does not - the problem occurs if you do dhcp, save, and then move to a
different subnet, and a dhcp again (which is when I found it - recently moved
offices, and needed new IP addresses for all my development systems)
As Wolfgang stated: the initial state (what CONFIG_IPADDR controls) doesn't
change the issue that the bug exists - it just controls when the bug
appears - sooner or later - but it is still there
Rather than call BootpCheckPkt() as I suggested - Ben could just check the
value of packetHandler... (if it is DhcpHandler, don't return)...
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DHCP regression on 2009-06
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5858fae38478d6399be4a16be3fc
causes a regression on my network's DHCP server.
The part of the diff that causes the problem:
#if defined(CONFIG_CMD_DHCP)
case DHCP:
- /* Start with a clean slate... */
BootpTry = 0;
- NetOurIP = 0;
- NetServerIP = getenv_IPaddr (serverip);
DhcpRequest(); /* Basically same as BOOTP */
break;
Since we are leaving the NetOurIP to whatever it was... The test at:
NetReceive():
case PROT_IP:
[snip]
tmp = NetReadIP(ip-ip_dst);
if (NetOurIP tmp != NetOurIP tmp != 0x) {
#ifdef CONFIG_MCAST_TFTP
if (Mcast_addr != tmp)
#endif
return;
}
Will return - (we leave the 'NetOurIP' set to the old value, the offered
address (what is in tmp) is not our's and tmp is not 0x).
You never process the DHCP_OFFER...
There are multiple ways of fixing things - setting NetOurIP = 0; (revert one
line of the change, which may expose the bug that Michael was trying to fix),
or try to be more tricky in the not our address check
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DHCP regression on 2009-06
On Fri 10 Jul 2009 12:27, Robin Getz pondered:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5
858fae38478d6399be4a16be3fc
causes a regression on my network's DHCP server.
The part of the diff that causes the problem:
#if defined(CONFIG_CMD_DHCP)
case DHCP:
- /* Start with a clean slate... */
BootpTry = 0;
- NetOurIP = 0;
- NetServerIP = getenv_IPaddr (serverip);
DhcpRequest(); /* Basically same as
BOOTP */
break;
Since we are leaving the NetOurIP to whatever it was... The test at:
NetReceive():
case PROT_IP:
[snip]
tmp = NetReadIP(ip-ip_dst);
if (NetOurIP tmp != NetOurIP tmp != 0x) {
#ifdef CONFIG_MCAST_TFTP
if (Mcast_addr != tmp)
#endif
return;
}
Will return - (we leave the 'NetOurIP' set to the old value, the offered
address (what is in tmp) is not our's and tmp is not 0x).
You never process the DHCP_OFFER...
There are multiple ways of fixing things - setting NetOurIP = 0;
(revert one line of the change, which may expose the bug that Michael
was trying to fix) or try to be more tricky in the not our address
check
I did verify that reverting the line exposes the bug that Michael fixed,
and so did this -- which seemed to work for my limited testing...
Index: net/bootp.c
===
--- net/bootp.c (revision 1961)
+++ net/bootp.c (working copy)
@@ -83,7 +83,7 @@
#endif
-static int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned src, unsigned len)
+int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned src, unsigned len)
{
Bootp_t *bp = (Bootp_t *) pkt;
int retval = 0;
Index: net/net.c
===
--- net/net.c (revision 1961)
+++ net/net.c (working copy)
@@ -1368,7 +1377,11 @@
return;
}
tmp = NetReadIP(ip-ip_dst);
- if (NetOurIP tmp != NetOurIP tmp != 0x) {
+ if (NetOurIP tmp != NetOurIP tmp != 0x
+ BootpCheckPkt((uchar *)ip +IP_HDR_SIZE,
+ntohs(ip-udp_dst),
+ntohs(ip-udp_src),
+ntohs(ip-udp_len) - 8)) {
#ifdef CONFIG_MCAST_TFTP
if (Mcast_addr != tmp)
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] - sanve the server's mac address...
On Wed 8 Jul 2009 14:50, Robin Getz pondered:
Linux's netconsole works much better when you can pass it the MAC
address of the server. (otherwise it just uses broadcast, which
everyone else on my network complains about :)
This sets the evn var serveraddr (to match ethaddr), so that you
can pass it to linux with whatever bootargs you want to
addnetconsole=set bootargs $(bootargs)
netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
I'm sure this is white space damaged - but you get the idea...
Wolfgang - did you want me to push this through the Blackfin tree
(via Mike) or wait for Ben?
Index: net/net.c
===
--- net/net.c (revision 1961)
+++ net/net.c (working copy)
@@ -1273,6 +1273,15 @@
/* are we waiting for a reply */
if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC)
break;
+
+#ifdef CONFIG_KEEP_SERVERADDR
+ if (NetServerIP == NetArpWaitPacketIP) {
+ char buf[20];
+ sprintf(buf, %pM, arp-ar_data);
+ setenv(serveraddr, buf);
+ }
+#endif
+
#ifdef ET_DEBUG
printf(Got ARP REPLY, set server/gtwy eth addr
(%pM)\n,
arp-ar_data)
___
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] - sanve the server's mac address...
On Thu 9 Jul 2009 15:45, Wolfgang Denk pondered: Dear Robin Getz, In message 200907091112.47264.rg...@blackfin.uclinux.org you wrote: On Wed 8 Jul 2009 14:50, Robin Getz pondered: Linux's netconsole works much better when you can pass it the MAC address of the server. (otherwise it just uses broadcast, which everyone else on my network complains about :) This sets the evn var serveraddr (to match ethaddr), so that you can pass it to linux with whatever bootargs you want to addnetconsole=set bootargs $(bootargs) netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr) I'm sure this is white space damaged - but you get the idea... Wolfgang - did you want me to push this through the Blackfin tree (via Mike) or wait for Ben? If at all ? Do you have some comments on it? - if so - that is that the RFC is for... this has to go through Ben and his tree. Note though that I don't think this is intended for inclusion yet - mind the RFC part in the subject. I guess - what is the reasonable amount of time to wait for a comment before I just resend with a [PATCH] subject line? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Wed 8 Jul 2009 11:51, Wolfgang Denk pondered: But we could prepend the typical header which brings us to something like this: You could do it, but you are eventually not permitted to do it legally. The fact that you must include the IBM copyright notice, this paragraph, and the preceding two paragraphs in the transferred software may or may not be compatible with GPL - IANAL... GPLv2 (http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt) states: 6. [snip] You may not impose any further restrictions on the recipients' exercise of the rights granted herein. [snip] I think that is pretty clear. The IBM notice is not GPL2 compatible - since it places additional restrictions on the end user. In fact, in looking closer - the patent license are completely incompatible... IBM: * No license under IBM patents or * patent applications is to be implied by the copyright license. GPLv2: if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. However - your milage may vary - I'm not a lawyer - Anyone who looks to technical mailing lists for licensing compatibility questions is going to get bad advice. This may be one of those times... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] - sanve the server's mac address...
Linux's netconsole works much better when you can pass it the MAC address of
the server. (otherwise it just uses broadcast, which everyone else on my
network complains about :)
This sets the evn var serveraddr (to match ethaddr), so that you can pass
it to linux with whatever bootargs you want to
addnetconsole=set bootargs $(bootargs)
netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
I'm sure this is white space damaged - but you get the idea...
Index: net/net.c
===
--- net/net.c (revision 1961)
+++ net/net.c (working copy)
@@ -1273,6 +1273,15 @@
/* are we waiting for a reply */
if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC)
break;
+
+#ifdef CONFIG_KEEP_SERVERADDR
+ if (NetServerIP == NetArpWaitPacketIP) {
+ char buf[20];
+ sprintf(buf, %pM, arp-ar_data);
+ setenv(serveraddr, buf);
+ }
+#endif
+
#ifdef ET_DEBUG
printf(Got ARP REPLY, set server/gtwy eth addr
(%pM)\n,
arp-ar_data)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3?
On Mon 6 Jul 2009 06:55, Wolfgang Denk pondered: I am definitely _pro_ going for GPLv3. I am also realizing the efforts and the time this will take. I'm also glad that you acknowledge that you will loose developers, and users... So it seems we can set up something like a plan: Short term goal: Clean up the existing license conflicts in U-Boot. This is a task that is completely independent of the GPLv2 versus GPLv3 discussion - it must be done in any case. Medium term goal: Analyze which parts of U-Boot are implemented by GPLv2-only code, and evaluate options to convert these into GPLv2+later. Long term goal: Move U-Boot to GPLv3. And -- since some of us will require to fork at this time (it is not a threat, it is not I don't like GPLv3, it is just me trying to plainly state the facts) - can we _plan_ for this, as part of the Long term goal? Where someone else takes over the code base - pre switching to GPLv3 (or pre-dropping features when switching to GPLv2+later). That way - contributors who still wish to place their contributions under a GPLv2 license, can do so? Contributors who wish to provide features under GPLv3 only can do so as well... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] Update malloc to dlmalloc version 2.8.4
On Tue 7 Jul 2009 15:49, Kumar Gala pondered: Where, do you mean bloat-o-meter? rg...@imhotep:~/linux-2.6.x ./scripts/bloat-o-meter usage: ./scripts/bloat-o-meter file1 file2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Thu 2 Jul 2009 09:56, Richard Stallman pondered: Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. The way I read that is that it is the unit you are on will have it's radio off, I think you have misinterpreted those words. Denying a user or a machine access to a network means cutting off communication in the network, not altering the machine. If the cell phone operator's rule says that operating of a modified device should not effect non-modified devices in close proximity (jamming - which I think meets the materially and adversely affects the operation of the network statement) - in a TDMA network (like GSM is) - the only way to enforce that rule - is on the client side - not on the network side. There is nothing on the network side you can do to stop that that I'm aware of. I'm aware that most devices today separate the datapump and the application processor, but this doesn't seem to be the trend - the trend is run both on the same CPU (as it decreases the cost). This clause is not an exception to the requirement for installation information. Cell phones must offer installation information just like other User Products. Right - but the cell phone provider should have the ability to alter the state of the device (not allow the radio to be turned on), so it can't adversely affects the operation of the network - shouldn't they? Or is this where one person's freedom (the ability to modify their phone, and turn it into a jamming device), is more important than the freedom of everyone else to actually use their phones on the same network. (Which actually - wouldn't be a completely bad idea - when I have been standing near someone talking too loud into their phone in a public place, I often wish for a jam the network app on my phone :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Thu 2 Jul 2009 12:11, Larry Johnson pondered: In the United States, most radio transmitters must be type accepted (certified) by the Federal Communications Commission. Modification voids the type acceptance, so operating a modified mobile phone on its original frequencies would be illegal regardless of what the phone company's rules say. However, no certification is necessary for transmitters operated according to the rules for the Amateur Radio Service. Thus, an licensed amateur could legally use a modified mobile phone, provided it transmitted on frequencies allocated for amateur radio and met the other requirements for amateur operation, including not causing harmful interference to other services. Assuming that the _licensed_ amateur could modify the phone enough that it _could_ operate on frequencies allocated for amateur use. The only thing that would be potentially close is a European GSM phone: Rx Tx E-GSM-900 880.0–915.0 925.0–960.0 MHz R-GSM-900 876.0–915.0 921.0–960.0 MHz T-GSM-900 870.4–876.0 915.4–921.0 MHz the US amateur band at 902 - 928 MHz. I don't think any of the CDMA phones are close enough to the amateur bands to have a hope of working - but I'm not as familiar with CDMA as GSM. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wed 1 Jul 2009 07:45, Richard Stallman pondered: Not to go down a rat hole - but as a normal part of development of non-free software, people use emacs, gcc, and gdb all the time - you aren't proud of the contributions you made to those projects? Yes, I am, but not because they help proprietary software. http://www.fsf.org/licensing/licenses/gpl-faq.html#CanIUseGPLToolsForNF As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction. We made the decision because there were other tools comparable to Bison which already permitted use for non-free programs. If you aren't happy that they help proprietary software - why not change the license to make it so? You recently had the chance to do that with the gcc runtime libraries - but you (or the FSF/GCC steering committee) also decided not to. http://www.fsf.org/licensing/licenses/gcc-exception-faq.html However, the FSF decided long ago to allow developers to use GCC's libraries to compile any program, regardless of its license. [snip] We decided to permit this because forbidding it seemed likely to backfire, and because using small libraries to limit the use of GCC seemed like the tail wagging the dog. I don't understand the how on one hand there is the uncompromising attitude on ethical issues (at least according to wikipedia) - but the FSF decides the practical considerations for other projects - the tail wagging the dog. How is the certification authority issue - whether is is a cell carrier (which the GPL3 says is an acceptable certification authority) and the FDA (which the GPL3 does not say is acceptable) determine when something is the tail or the dog? I just don't understand the difference? -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Wed 1 Jul 2009 07:46, Richard Stallman pondered: I can't see how someone can deny access to the network, while still allowing anyone's software to be run on the device, without some sort of key system in the networking hardware - is that what you had in mind? This is aimed at cell phone networks: it recognizes they are allowed to make the network refuse to talk to a phone if the users's changes cause the phone to screw up the network. There is a difference between the network not talking to you, and you not able to be on the network. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. The way I read that is that it is the unit you are on will have it's radio off, and you will not be able to use it, not the network will not talk to you. You could apply the same thing to VoIP phones... When manufacture makes a VoIP phone, they test it against various networking tests (all internal, since they are not required to release this info) to make sure that it acts properly on the network. They sign this image to make sure that flash is not failing. If something doesn't match the signature - how can the manufacture believe that is doesn't violate the rules or protocols of ethernet? So - it denies access to the network - by not booting that image. That is the only way that they can deny access to the network all SoC variations that I'm familiar with. This is in no way trying to interperate the GPL3 for others (that is for lawyers to do) - but just a question from an interested developer - to me - it seems like tivo all over again. All Tivo needs to do is just make the network a piece of their application - and they have an out... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tue 30 Jun 2009 15:12, Richard Stallman pondered: That is great - and I applaud your efforts. I think that the work you are doing is valuable, and the contributions you have made have been critically important to the free and closed software developments that people to today. If you mean that my work has contrubuted to non-free software developments, I am not proud of that. It is not a good thing that people develop or use non-free software. Not to go down a rat hole - but as a normal part of development of non-free software, people use emacs, gcc, and gdb all the time - you aren't proud of the contributions you made to those projects? I was trying to say that your efforts have changed the face of computing in general, in both that it has created the free and non-free software software categories, and helped inform users of their freedoms they should be expecting. To use someone else's words - an IDC 2006 study Open Source in Global Software: Market Impact, Disruption, and Business Models described free software and open source as the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980s and found that over 70 percent of all developers are leveraging open-source and free software. In any movement - there needs to be the golden standard - that is unwavering in its ethics and standards. Not everyone likes that standard - but it needs to be there. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tue 30 Jun 2009 15:12, Richard Stallman pondered: While I probably would not want to change my glucometer, the practice of designing hardware so that people cannot change it is becoming more and more of a threat to our freedom in general. It is simple economics - it is about consumers making choices. Most people in the general public don't _want_ to change anything, so they buy the cheapest unit. The price of that unit drops as the volume goes up. The suppliers compete, and integrate more into their ICs. The price drops more, and consumers line up to buy more, since the price is now cheaper. People don't know what they are loosing if they don't know it exists. If a product is required to be locked down by a certifying authority, (whom ever that may be), they can't use GPL3 code. If the users' freedom is protected by GPLv3, the certifying authority that attacks users' freedom blocks the use of this code. While I recognize that developers who get in the middle of this battle did not cause the battle, I will not surrender the fight just for their sake. So understand where the fight needs to take place. It's not at the developer level - its at the regulator level. This really has nothing to do with tivoization, since in the Tivo case - they had no greater certification authority - and were just trying to restrict people's use. These companies (if I understand the facts correctly from what people have said here) are doing the same thing to the user that tivo does, so it is equally wrong. The wrong is not in their motive, it is in what they do. Suppose there were an official certification authority for video players. (Hollywood could probably buy such a law if it wanted to; Obama would be glad to sign it.) Would that make the tivo ok? Obviously not. Thus, the existence of a certification authority does not alter the concluisions about the ethical issue of tivoization. So - why does the the GPL3 have an out for networking? (which is going to be abused). From the GPL3: Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. I can't see how someone can deny access to the network, while still allowing anyone's software to be run on the device, without some sort of key system in the networking hardware - is that what you had in mind? I support effective steps to protect safety for the users of medical devices. But, as I've explained above, that does not require tivoization, so it does not excuse tivoization either. I understand the moral dilemma, and your viewpoint. Unfortunately, no one who writes the standards is asking my (or anyone on this list's) opinion of what the certification process is. -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Tue 30 Jun 2009 15:12, Richard Stallman pondered: Maybe you should be working with these types of certification authorities, rather than individual developers? I would be glad to do so. I have no contacts in the FDA, and I am not so famous that mere mention of my name would make them pay attention. But maybe some of these developers could introduce me to someone useful to talk with. If you know them, would you like to try? Can't promise much - but I can poke around. I'm sure that you could get a meeting with Ms Hamburg or Aneesh Chopra before I could Who are they? Can you tell me how to contact them? Aneesh Chopra was Virginia’s Fourth Secretary of Technology, and has recently been sworn in as the Federal CTO. http://radar.oreilly.com/2009/04/aneesh-chopra-great-federal-cto.html http://www.fda.gov/AboutFDA/CommissionersPage/default.htm I will send mail to fetch that page. If I see any chance of discussing this with them, I will at that point want to read the relevant certifications so that I can speak with them fully briefed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Thu 25 Jun 2009 10:41, Detlev Zundel pondered: Hi Mike, It is this certification is only possible like we say attitude which I seriously question. whether you question this attitude doesnt matter. you arent a lawyer in general, you arent a lawyer for these companies, and you arent indemnifying them. their legal review says that it's a requirement, so it is now a requirement for the software. anything beyond that is irrelevant. Now was this so hard? This is actually an important fact that it is a legal requirement for a company - thanks. As a quick web research did not help, if this is a legal requirement, then can you point me to the law which requires such a thing? As Mike said - there are many organisations which require this. Some from a legal standpoint, some from a certification standpoint. It depends on the end product. Your ability not to find them doesn't change the fact that they do exist. Search for: IEC 61508-3 : Functional safety of E/E/PE safety-related systems Part 3: Software requirements http://en.wikipedia.org/wiki/IEC_61508 IEC 601-1-4 : Safety Requirements for Programmable Electronic Medical Systems ANSI/UL 1998 : Standard for Safety Software in Programmable Components There are other that are industry specific - the gambling industry is a good one (that ksi already pointed out) http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf 1.080 Control program requirements. (a) Employ a mechanism approved by the chairman which verifies that all control program components, including data and graphic information, are authentic copies of the approved components. The chairman may require tests to verify that components used by Nevada licensees are approved components. The verification mechanism must have an error rate of less than 1 in 10 to the 38th power and must prevent the execution of any control program component if any component is determined to be invalid. That doesn't use the words secure boot - but if that is what the chairman of the Nevada gaming commision decides - then that is what is is... As Mike has stated - we work on many devices who's products would fall under the GPL 3's “User Products” category - who's manufactures have told us No GPL3. They have this right - the right to use the software - or the right to choose something else. They have indicated they will exercise this right - so far - I believe them. If Wolfgang decides to remove all the GPL-2 only code, and re-write that, and release U-Boot under GPL-3 - that is his right - he needs to do the things that let him sleep better at night. If he decides to do so - it just means that I will need to exercise my rights - and either fork, or go work on MicroMonitor - neither are really that appealing for me - but they are the only choice I have with a GPL-3 U-Boot. Part of any freedom is the freedom to have an amicable disagreement, and make an alternative choice. I will only need to make that choice when I see a commit to: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=COPYING;hb=HEAD which updates it to GPL3. Until then - it is just time wasted, when I should be doing more productive things. :) -Robin Although this is a bad analogy for the existing topic - I have always told my kids - part of freedom is the right to make choices, and allow others to make choices you don't agree with. If you choose to believe your water bottle is some sort of deity, and want to worship it - that is fine. I'll stand up and defend your rights to do so. I will still think you are nuts and will not join you in your water bottle worship (no offence meant to any existing, future or past water bottle worshippers). Freedom does not mean my freedom - it is not my right to enforce my belief system on you, but my obligation to stand and defend your rights to do something I don't like. Pushing one's person's belief system on another belongs in comp.sys.mac.advocacy and no where else. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
On Mon 29 Jun 2009 14:48, Richard Stallman pondered: As Mike has stated - we work on many devices who's products would fall under the GPL 3's User Products category - who's manufactures have told us No GPL3. Would you like to describe one such product? Portable hand held medical devices - such as Glucometers. They fall into both categories. They are medical devices, who's bad software could cause a user to give them selves too much insulin (hypoglycemia - pass out - seizure - death), or too little insulin (Hyperglycaemia - stupor - coma - death). Yeah, death is over the top - as most diabetics understand their body well enough not recognise the signs much before the pass out stages - but for the person who isn't familiar with things - it is possible. They are marketted, and purchased by end consumers (Amazon shows 115 results in their search), and I would think that would make them fall into the User Products. All the product types discussed so far are outside the category of User Products. The laws you cites also seem to apply to things which are not User Products. I don't think I had any links to laws - only specifications. Years ago - I helped develop a cloths dryer which needed to pass UL 1998 - since the cut off switch (open the door, the dryer stops spinning), was a GPIO on a 8-bit microcontroller... White goods are as consumer/user products as you can get - all need to pass some sort of safety spec, when software failures can hurt people. They have this right - the right to use the software - or the right to choose something else. They have indicated they will exercise this right - so far - I believe them. If a company seeks to restrict users like you and me, I strongly hope my software does not help them. And I think that is great that you feel like that. You have every right to limit the use of the software you write and support - just like I have that same right not to feel the same way. I feel that companies should have the right to choose how to use the software I develop, as long they give things back, and I can use it on _my_ hardware (which the GPL2 allows/encourages) - I don't really care what they do on their hardware. That is their business, not mine. I hope that you can respect my choice - and not try to convince me or others that your choices are superior to mine. -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MMC issues with cards formatted as SuperFloppy format?
Andy:
I was running into a issues, and just wanted to double check that it should be
able to be handled - and the problem wasn't in the arch specific mmc driver
somewhere
If you format the card with unpartitioned Removable device ('super floppy'
format: A super floppy layout is one in which there is no MBR, so there is no
partition table. The entire disk (from start to end) is one giant partition.)
# dd if=/dev/zero of=/dev/sda bs=512 count=1
# mkdosfs -I /dev/sda
This will work OK in Windows and Linux hosts - it will just get mounted
on /dev/sda.
When I pop it into U-Boot, I get something that thinks it _is_ a DOS parition,
with a MBR (some extra debugging turned on). and the partition offset gets
messed up, and everything falls apart.
bfin mmcinit
CID information:
Manufacturer ID: 03
OEM/Application ID:5344
Product name: SD256
Product Revision: 8.0
Product Serial Number: 544862406
Manufacturing Date:07/08
SD Card detected (RCA 32769)
CSD information:
CSD structure version: 1.0
Card command classes:5f5
Max trans speed: 25MHz
Read block length: 512
Write block length: 512
Card capacity: 252968960 bytes
mmc_bread: dev 0, start 16, blkcnt 1
mmc_bread: dev 0, start 0, blkcnt 1
mmc_bread: dev 0, start 0, blkcnt 1
mmc_bread: dev 0, start 0, blkcnt 1
bfin fatinfo mmc
fat_register_device
mmc_bread: dev 0, start 0, blkcnt 1
mmc_bread: dev 0, start 0, blkcnt 1
## Valid DOS partition found ##
part_offset = 778135908
Interface: MMC
Device 0: Vendor: Man 035344 Snr 2079f0c6 Rev: 8 0 Prod: SD256
Type: Hard Disk
Capacity: 241.2 MB = 0.2 GB (494080 x 512)
disk_read
mmc_bread: dev 0, start 778135908, blkcnt 1
mmc: bread failed, status = 0008, card status = 8900
Error: broken fs_type sign
It looks like a problem in common fat partition management code.
Can you confirm the same happens on your systems?
Thanks
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
