[U-Boot] RFC: Testing U-Boot Part 1

Simon Glass sjg at chromium.org
Sat Aug 27 02:25:16 CEST 2011


Hi Mike,

On Fri, Aug 26, 2011 at 1:55 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Thursday, August 25, 2011 23:32:38 Simon Glass wrote:
>> 1. What should I call the architecture? I have so far called it 'native'.
>> 2. What should I call the vendor (board/xxx)? 'test' or 'sandbox'?
>> 3. What should I call the board? Is that 'sandbox'?
>
> as Graeme said, just call them all "sandbox"

OK, sandbox it is.

>
>> 4. When I create a driver, like the serial test driver, should that be
>> serial_test.c, test_serial.c, sandbox_serial or something else?
>
> i think it depends on its function.  if the serial driver actually goes to
> std{in,err,out}, then perhaps "serial/sandbox_stdio.c".  let's not assume
> we'll only ever have one pseudo driver that we can use under the sandbox :).

OK well I suppose I can start with sandbox and we can see where it takes us.

>
>> Wolfgang Denk: I'm not sure what you mean by "a mocked remote host".
>> We should be
>> able to send and receive packets from a real network interface as
>> well.
>>
>> - 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.

Regards,
Simon

>


More information about the U-Boot mailing list