Hi Simon,
On Fri, Aug 26, 2011 at 1:32 PM, Simon Glass sjg@chromium.org wrote:
Hi,
Thanks all for comments. It sounds like people are keen on the idea so far as it goes. I will work on a patch set complete enough to bring up a U-Boot prompt, allowing typing of 'help' and with a special segfault feature for anything else.
Before I do this, and to avoid me redoing work later:
- What should I call the architecture? I have so far called it 'native'.
sandbox
- What should I call the vendor (board/xxx)? 'test' or 'sandbox'?
sandbox
- What should I call the board? Is that 'sandbox'?
sandbox
- 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 guess you'll have /drivers/serial/sandbox.c, /drivers/net/sandbox.c etc.
/include/configs/sandbox.h will need to include defaults for how these devices are configured. For example, you may want to have the sandbox serial go to /dev/ttyS0 or /dev/ttyS1
Make sure that printf() goes through U-Boot printf() not the host's libc
And have you dealt with putc() and getc() hooking so that the U-Boot stdio can go to either the hosts stdio or a serial port?
- I need an arch/xxx/lib/board.c. Rather than try to create a new
minimal one, I think I should copy an existing one and change it as little as possible (in the light of Graeme's comments and to avoid yet another version of this file). Thoughts?
Make this board an example of a New World Order ;) - Seriously, take arch/x86/lib/board.c as it has arrays for both init_f and init_r. If you look at board_init_f it has very little other than the loop. But board_init_r is a mess - It starts out as a loop and finished being a sequence of function calls. Implement board_init_r so it consists of only a processing loop - Debatable as to whether or not to but the while(1) { main_loop;} as a final 'init' function or whether to have this after the init loop is processed
I imagine that sandbox will have no _f init functions as there will be no relocation anyway. Still, put in board_init_f but have an empty sequence.
[snip]
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.
Yes, using a real interface (loopback even) would be good as you can then also test that your host's tftp server is working
[snip]
Regards,
Graeme