Hi Michal,
back to your requests and objections I've built up a new patch set for evaluation. Some of the changes relate to the Microblaze platform rather than the network driver.
1) U-Boot configuration variables vs. xparameters.h ---------------------------------------------------------------------- I've tried to find a compromise between the U-Boot coding and configuration style and your preference. But at least in the point of the many many CPP conditional directives I can not reduce the code. I can move the code only to another place. I need a converstion from the automaticaly generated content of xparameters.h to the U-Boot configuration space. Now you can find this conversion matrix in a new platform header, xconversions.h -- I've placed the header in board/xilinx/microblaze-generic/ I think, we can find a better place.
The conversion matrix avoids all the wrong configuration variables inside U-Boot code beginning with XILINX_ (and not CONFIG_) and we can expand the configuration to new software related options we never get from hardware (example special interface naming). This mechanism can also be used by other driver and platform code, for example arch/microblaze/cpu/cache.c and arch/microblaze/lib/bootm.c (use XILINX_USE_DCACHE instead of ex. CONFIG_XILINX_DCACHE), common/cmd_mfsl.c (use XILINX_FSL_NUMBER instead of ex. CONFIG_XILINX_FSL), serial_xuartlite.c (use XILINX_UARTLITE_BASEADDR, XILINX_UARTLITE_BASEADDR1, ...), and probably also in xilinx_emaclite.c and xilinx_axi_emac.c when we extand a multi-IP support as we have done for the LL TEMAC now. Sure we have to work on, but it's another case (I can make some patches if you want)
Another but not currently existing feasibility would be to generate a U-Boot conform xparameters.h, for example CONFIG_XILINX_LL_TEMAC0_BASE_ADDR instead of XILINX_LLTEMAC_BASEADDR. You and I, we have it in hand. We can change the Xilinx BSP in the near future. You in PataLinux and I in my own home-brewed BSP generator TPOS.
2) Standard initialization vs. multiple direct calls from platform ---------------------------------------------------------------------- Returning to the topic "standard" initialization. The last patch will show the differences bwetween your prefered way to do all in board init and my applicable standard initializition (a single call to the driver). Please look at it in the code and decide for yourself.
We need a forward-looking decision, what kind of initialization, we want to use. Do we want to copy and paste the standard initialization steps from ip core to ip core (board init) and from platform to platform (Microplace, PPC405, PPC440) or make a simple call to the driver?
My preferences is to call the driver from platform and let him run all the necessary steps, that I do not want knowing on platform side.