[U-Boot] [PREVIEW] LL TEMAC v10 refactored -- for evaluation only

[Stephan Linz]

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.


-- 
Best regards,
Stephan Linz
______________________________________________________________________________
MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start
OpenDCC: http://www.li-pro.net/opendcc.phtml
PC/M: http://www.li-pro.net/pcm.phtml
Sourceforge: http://sourceforge.net/users/slz
Gitorious: https://gitorious.org/~slz