Stephan Linz wrote:
Am Donnerstag, den 05.01.2012, 20:19 +0100 schrieb Wolfgang Denk:
Dear Stephan Linz,
In message <1325783490.7827.45.camel@keto> you wrote:
Michals latest Microblaze platform patches will enable this driver for
board/xilinx/microblaze-generic and we know about a success story on a
propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda.
-- snip --
So I'll rework the driver and
present a new v8 patch as soon as possible.
OK. Please submit it only if it comes with code that references the
driver.
Hi Wolfgang,
I understand your opinions to stick together all the different code
fragments. Unfortunately, this driver will be used by systems with
synthesized hardware (FPGA SoftCPU systems). The target board (hardware
around the FPGA) will be fixed but the content (CPU, controller, busses,
interfacess, addresses, ...) will be variable and not fixed. That's why
we use a so named microblaze-generic board configuration controlled by
the header xparameters.h in board directory. The default content of
xparameters.h is really only basic and enables not nearly half of all
possibilities. For example the default configuration in xparameters.h
will enable the Xilinx EMAC-Lite driver (with XILINX_EMACLITE_BASEADDR)
but do nothing to enable the Xilinx AXI-EMAC driver (with
XILINX_AXIEMAC_BASEADDR) -- it makes no sense to enable both at the same
time.
Every fpga system is different that's why I have created microblaze-generic
board
and BSP generator to generate xparameters.h and config.mk for specific
configurations.
Make no sense to create new board for every configuration.
The same arguments is valid for xilinx ppc405/ppc440 systems where I am still
don't like that there are avnet boards and maybe others.
I'll provide the same way for the Xilinx LL_TEMAC driver as for the
Xilinx AXI-EMAC driver. I prepare the microblaze-generic board code to
support all potential Ethernet drivers but leave out the specific usage.
You are right when you say that there is no code that refere to the new
driver code -- there are also no configuration for this. And yes we
adapt/change the xparameters.h out of mainline tree to enable the driver
code -- but I think, that is not really a "out of tree port".
But what would be the best implementation for unspecified targets here?
@Michal: Is there anybody who use the current default configuration from
microblaze-generic/xparameters.h on a real FPGA system design? If not we
could expand xparameters.h with a fantasy configuration to enable all
potential drivers used on a Microblaze system. So we have a reference to
driver code and can test the rebuild again and again with a simple 'make
microblaze-generic'. What do you mean?
It is the same situation as is for axi-emac and even emaclite.
xparamters.h/config.mk are for any old platform which none uses it.
IMHO Stephan suggestion could work - enable all drivers in xparameters.h
and enable code compilation.
I can also extend my testing system to compile u-boot with ll_temac and
test it on qemu every day.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
