Reply by March 4, 20052005-03-04
>pbreed@netburner.com writes: >> A part with similar capabilites is availbile Today from FreeScale. >> 32 Bits, 64K Ram, 512K flash 10/100 Mac, CAN,I2C, 3 Uarts, SPI 8 Timers, >> 80Mhz etc.. etc... > >How does an 80 MHz Coldfire perform compared to an 80 MHz ARM7?
I would expect the performance to be almost identical. Both are single cycle flash access, both a risk like. The Motorola site has some MIPS benchmarks for the 5282 I think it's about 78 Mips for the 80 Mhz 5282.
>Not that we know the rated speed of unannounced Atmel parts, but it >could perhaps reasonable be expected to compare to the AT91SAM7A3, >which is stated to offer 54 MIPS at 60 MHz.
>If I want to use GDB hosted on Linux to debug a 5282 through the BDM >port, do I have to buy an expensive interface box, or is there a cheap >box or a free design I can use?
There are a number of low cost BDM's (BDM is Freescales version f JTAG debugging) for the coldfire. Both Linux and Windows hosted. Out (Netburner's) 5282 product uses the Network to upload/download code and a non maskible serial routine running as a GDB stub. If you have to have the BDM interface companies that have low cost ColdFire BDMs are http://www.pemicro.com/ http://www.cybertec.com.au/ http://www.macraigor.com/wiggler.htm Paul
Reply by Stephen Pelc March 4, 20052005-03-04
On Wed, 02 Mar 2005 15:39:34 GMT,
stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) wrote:

>We have (finally) got round to testing our PowerNet TCP/IP >stack on an ARM with 120k Flash and 64k RAM. With Telnet, >multi-threaded HTTP server with CGI and ASP, it all fits >and runs. Connection is over Ethernet (port-mapped RTL8019AS). >The limitation is in the number of free buffers and number >of simultaneous open connections. > >We'll know in a day or two what we can fit into 32k of RAM.
Preliminary tests show that the full PowerNet system works fine in 32kb RAM, and with a few tweaks (in progress) will work with 16kb RAM. I'm pleased that a Usenet group discussion has improved our product. Thank you all! Stephen -- Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by Markus Zingg March 4, 20052005-03-04
On Fri, 04 Mar 2005 00:13:00 GMT, Darin Johnson <darin_@_usa_._net>
wrote:

>Markus Zingg <m.zingg@nct.ch> writes: > >> I would be carefull when it comes to the tricks mentioned by some >> posters here. Don't forget that there are SYN flood attacks, tear drop >> attacks and other malicious activity out there in the internet waiting >> to hit your implementation. You must handle these kind of things >> reasonably well in a comercial product or otherwise you will have >> lot's of problems. > >For reference, what sorts of things should an ethernet implementation >test for in general? For instance, if there's a product that works >great in the lab, but turns out to be less robust when put into a >customer's intranet? Not just things to test the software, but >stressing the hardware too. Is there a nice checklist out there >somewhere?
I haven't found a checklist, but out of my experience the timely order of network events is something that is hard to test. In my project, most of the bug's that ocured after lab testing were in this area. To give you an example, one time our implementation ran into problems if the answer to a second ARP query arrived before the first one. Was a stupid typo, but it got undiscoverd in the lab. What you SHOULD do under all circumstances is visit some "hacker" sites, collect the latest attack tools and bomb your implementation with it. If you don't do it, you can bet that someone else will. Another thing you can do is to use a second device of yours and programm it to generate all these ugly situations you fear most in your implementation. I.e. make sure to generate out of order pakets, fragmented pakets and so on. It's a matter of fact that you can generate the most exotic pakets with your own hardware the easiest way since even the raw socket interface does not allow to generate all kind of ugly things. Such a test device of yours then can also be used to verify future releases of your software. Markus
Reply by Stephen Pelc March 4, 20052005-03-04
On Thu, 3 Mar 2005 07:44:23 +0100, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>I am trying to figure out if we need more than 64 kB in the part or not. >My conclusion so far is that 64 kB is OK for small systems, but not >for "fullblown" systems.
From our experience, the RAM hogs in PowerNet are: 1) buffers for TCP packets, retries, windows ... 2) servers 64k RAM is enough. PowerNet can run in 32k RAM, but other application demands for RAM may make it preferable to support only one connection for the Telnet and HTTP servers. Stephen -- Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by March 3, 20052005-03-03
pbreed@netburner.com writes:
> A part with similar capabilites is availbile Today from FreeScale. > 32 Bits, 64K Ram, 512K flash 10/100 Mac, CAN,I2C, 3 Uarts, SPI 8 Timers, > 80Mhz etc.. etc...
How does an 80 MHz Coldfire perform compared to an 80 MHz ARM7? Not that we know the rated speed of unannounced Atmel parts, but it could perhaps reasonable be expected to compare to the AT91SAM7A3, which is stated to offer 54 MIPS at 60 MHz. If I want to use GDB hosted on Linux to debug a 5282 through the BDM port, do I have to buy an expensive interface box, or is there a cheap box or a free design I can use? Thanks, Eric
Reply by March 3, 20052005-03-03
>It is not available yet.
A part with similar capabilites is availbile Today from FreeScale. 32 Bits, 64K Ram, 512K flash 10/100 Mac, CAN,I2C, 3 Uarts, SPI 8 Timers, 80Mhz etc.. etc... See: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF5282&nodeId=018rH3YTLC00M9 Or Search for the MCF5282 Paul www.netburner.com
Reply by March 3, 20052005-03-03
Markus Zingg <m.zingg@nct.ch> writes:

> I would be carefull when it comes to the tricks mentioned by some > posters here. Don't forget that there are SYN flood attacks, tear drop > attacks and other malicious activity out there in the internet waiting > to hit your implementation. You must handle these kind of things > reasonably well in a comercial product or otherwise you will have > lot's of problems.
For reference, what sorts of things should an ethernet implementation test for in general? For instance, if there's a product that works great in the lab, but turns out to be less robust when put into a customer's intranet? Not just things to test the software, but stressing the hardware too. Is there a nice checklist out there somewhere? -- Darin Johnson Support your right to own gnus.
Reply by Markus Zingg March 3, 20052005-03-03
On Thu, 03 Mar 2005 07:53:40 -0700, "Richard H." <rh86@no.spam> wrote:

>Markus Zingg wrote: >> Especially the SYN flood thing requieres implementing SYN cookies or >> other kind of counter measures or else the limitted resources of an >> embedded system are eaten up instantly. > >Markus, > >What approach did you implement for SYN cookies? > >I've seen a couple schemes - one crypto-based, the other a scheme for >encoding the setup vars in the ISN. Both seem to have challenges, not >the least of which is the limited field size of the Seq# to work with >(never mind that it violates the requirement for ISN randomization).
We encode the setup vars and then create an MD5 hash out of this which is used as the ISN. The hash key is varied randomly and only valid for a certain duration. The SYN/ACK therefore must arrive within this time window to be acepted.
>For example, did you sacrifice the options header / certain MSS >increments in the process? IIRC, this is the one big point of >compromise to fit in the available field space, with the being 0 RAM >used until the reply SYN-ACK arrives (i.e., fairly impervious to SYN >flooding).
The compromise is in reality not that big in that almost all TCP implementations use some popular MSS value. Then you can't trust the anounced MSS value anyways since there are implementations which anounce a bigger MSS than what they actually accept. Sometimes there are also gateways along the way which drop segments above a certain size but fail to send the propper ICMP anouncements. Often this is the case because a sysop firewalls everything but uses a router behind the firewall showing this behaviour. In such scenarios it's often impossible to tell wether the TCP implementation of the oponent is broken or if it's just a configuration issue. This is just one area where strict RFC compliance of your impelmenation alone does not guarnatee seamless operation in the field. I do agree that such situatins are rare, but they DO exist. So it's wise to have a TCP implementation which is able to adapt the anounced MSS value acordingly or else you will have interoperabilty issues. The problem with these kind of things are that they ocure at the point in time your product is in the market. It's even nastier that although your product may follows the RFC's, the customer will point at you since it's Windows PC's TCP implementation does adapt the anounced MSS and therefore work. It's quite difficult to discuss such issues with end users.... So you better prepare right from the start. Obviousely solving these kind of issues also uses code space and eventually also RAM. That's why I thought it's a good idea to bring this point to Ulf's attention. Markus
Reply by Markus Zingg March 3, 20052005-03-03
>> I would be carefull when it comes to the tricks mentioned by some posters >> here. Don't forget that there are SYN flood attacks, tear drop attacks and >> other malicious activity out there in the internet waiting to hit your >> implementation. You must handle these kind of things reasonably well in a >> comercial product or otherwise you will have lot's of problems. > >I'm not sure what you mean with "the tricks mentioned by some posters" >(perhaps you could be a little more specific?) but I would also like to >stress the importance of doing heavy testing of a TCP/IP stack. Send as >much "bad" packets to your stack as possible - others surely will.
I started my implementation about two years ago and back then all small TCP stack's I looked at could not resist SYN flood attacks not to mention more complicated attacks that are reality also. I do not say that they necesairly crash the device, but there are no counter measures at all in place. SYN flood attacks are nasty in that the attacker can easily hide origin by randomly varying the sender IP address. In normal day to day's live it's not feasable to track the source of an attack since it would requiere cooperation of sysadmins all across the way back to the attacker. In other words, such attacks can go on for hours thereby rendering an embedded device using this kind of unsecure TCP implementation useless. This CAN be a very important issue if the device is used in a productive envireonement. With "tricks" I mostly refered those implementations which try to keep state in the NIC's buffer, useing specially crafted sequence numbers et all. The randomness of initial sequence numbers is extremly important to avoid other kind of attacks (i.e. man in the middle) . If however bit's from the sequence number are used for other purposes as sugested, the randomness of the numbers can't be guaranteed to a high degree enough. I do see the obvious advantages that such tricks might have to save RAM et all, but not also considering security issues in todays times is probably only ok for hobby projects..
>> Another issue is how many systems out there simply do not play by the >> standards. We see systems anouncing MSS but then do not accept segments >> of this size etc. etc. So again, if this is for a heavily comercial kind >> of application you must consider these things too. > >Failure to adhere to the size of the MSS seems to be the most common way >to diverge from the RFC standards. This may work fine when talking to a >PC, but may result in communication failure when trying to talk to a small >embedded device. Lacking support for IP fragment reassembly also seems >quite common. Some stacks also leave out TCP's congestion control, which >may even lead to network overload. I fully agree with you: compliance with >RFCs is important.
I actually was refering to some Linux TCP versions which in fact anounce an MSS of say 1460 byte, but silently drop every segment bigger than 1420 bytes. So, the embedded TCP stack must implement a technique to slowly increase the MSS and maybe lower it if it sees that segments are lost. Not that this would be a problem, but it must be implemented and it uses code space and can't be ignored. Ignoreing these kind of issues leads to hard to explain interoperabilty problems.
>For a more thorough discussion of RFC compliance of small TCP/IP >implementations, please refer to my MOBISYS'2003 paper "Full TCP/IP for >8-bit architectures", available at >http://www.sics.se/~adam/mobisys2003.pdf
I currently don't have the time to read this document but surely will do so. I have no idea wether your implementation suffers in any of the points I put my finger to. What I can say here though is that out of my experience RFC compliance alone is often not enough. The stack also must be able to deal with non complying implementations - at least to some degree. Markus
Reply by Ulf Samuelsson March 3, 20052005-03-03
Eric Smith wrote:
> If you haven't yet decided the memory sizes, it's obviously quite > a way out yet. > > Or if you have already taped out a part with 64KB and are trying to > decide whether to introduce it as a product, the answer is yes. :-) > > Eric
I dont make decisions like this in Atmel, but sometimes I can make people reverse decisions by good arguments. If anyone has anything to complain about the Watchdog in the SAM7S series then I am the guy to talk to. Just wanted to know if the SRAM size was worthy of another crusade. It looks like we can live with 64KB of SRAM for a substantial part of the market. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB