Hi Simon,
On Fri, Aug 26, 2011 at 1:32 PM, Simon Glass <s...@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:
>
> 1. What should I call the architecture? I have so far called it 'native'.
sandbox
>
> 2. What should I call the vendor (board/xxx)? 'test' or 'sandbox'?
sandbox
>
> 3. What should I call the board? Is that 'sandbox'?
sandbox
>
> 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 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?
> 5. 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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
