On 06/29/2012 10:22 PM, Stephan Linz wrote:
Am Freitag, den 29.06.2012, 09:37 +0200 schrieb Michal Simek:
Call emaclite FDT registration when CONFIG_OF_CONTROL is used.
Signed-off-by: Michal Simekmonstr@monstr.eu
.../xilinx/microblaze-generic/microblaze-generic.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c b/board/xilinx/microblaze-generic/microblaze-generic.c index a1e2bfe..4a719ba 100644 --- a/board/xilinx/microblaze-generic/microblaze-generic.c +++ b/board/xilinx/microblaze-generic/microblaze-generic.c @@ -73,6 +73,9 @@ int board_eth_init(bd_t *bis) { int ret = 0;
+#ifdef CONFIG_OF_CONTROL
- ret |= xilinx_emaclite_init(bis);
+#else
First of all: I've successful tested on an AXI system on Avnet S6LX9 micro-module.
Now some words to the different configuration strategy. I prefer a seperation between the ongoing development without device tree support and the upcoming development with fdt support.
Could you split the development in the context of boards, for example:
OLD: Development w/o fdt in:
- board/xilinx/microblaze-generic/*
- configuration in include/configs/microblaze-generic.h
NEW: Development with fdt in:
- board/xilinx/microblaze-fdt/*
- configuration in include/configs/microblaze-fdt.h
So you can start with a really clean and slimmed board configuration for fdt development (especially the content of config header) and the old generic board support would be retained. Anytime in the future, when the generic configuration will become obsolete you can remove it.
I don't think this is good idea to split it. All the time when you split development to different trees/configuration they start to diverge and then you just need to spend more a more time to manage both.
My strategy will be to add both configuration together. It will have also demonstration purpose to show up differences.
If you want to use two boards you can.
Thanks, Michal