From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sat, 27 Aug 2011 12:23:27 +1000 Subject: [U-Boot] RFC: Testing U-Boot Part 1 In-Reply-To: References: <201108261655.18688.vapier@gentoo.org> Message-ID: <4E58551F.3080508@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 27/08/11 10:25, Simon Glass wrote: > Hi Mike, > > On Fri, Aug 26, 2011 at 1:55 PM, Mike Frysinger wrote: >> On Thursday, August 25, 2011 23:32:38 Simon Glass wrote: [snip] >>> - I mean that the tftp command will 'obtain' a file when it asks for >>> one, although the actual Ethernet layer is mocked and doesn't actually >>> go out on the wire. Imagine an Ethernet driver which has a half-baked >>> tftp server in it. Yes I also see value in actually using machine >>> interfaces since the testing can be more thorough. >> >> why not just build on top of tun/tap ? then we do get "real" network traffic, >> and you dont have to write your own tftp server because you can simply use the >> same exact one on your development machine that the board would connect to. >> -mike > > Because then you need to set up a real tftp server. It's fine to do > what you suggest, but if possible it would be nice to have > self-contained tests also, so long as it isn't too much work. > I don't consider having to set up a tftp server as a bad thing - Quite the opposite really. There is plenty of network code in U-Boot that will benefit from testing under the sandbox target because it is much easier to debug. And there will be minimal impact on U-Boot code (just a sandbox 'Ethernet' driver is all that will be needed) I am reminded of when the R&D department that developed to eNET board were doing the firmware development before the first prototypes were available - The created a HAL which used pcap from memory. I wasn't part of that team, so I really don't know the details... Regards, Graeme