Wolfgang et al,
I have a few board-specific tools that help with some board diagnostics and manufacturing processes. These tools are currently built in the "examples" directory, but are highly board-specific. (EEPROM programming, memory checking, Serial Number stamping, etc.)
Currently, the examples directory has board-specific binaries that it builds, but it does so based on the the ARCH variable, like this:
ifeq ($(ARCH),arm) LOAD_ADDR = 0xc100000 endif
ifeq ($(ARCH),mips) LOAD_ADDR = 0x80200000 -T mips.lds endif
ifeq ($(ARCH),nios) LOAD_ADDR = 0x00800000 -L $(gcclibdir)/m32 -T nios.lds endif
and:
# The following example is 8260 specific... ifeq ($(CPU),mpc8260) SREC += mem_to_mem_idma2intr.srec BIN += mem_to_mem_idma2intr.bin mem_to_mem_idma2intr endif
# Utility for resetting i82559 EEPROM ifeq ($(BOARD),oxc) SREC += eepro100_eeprom.srec BIN += eepro100_eeprom.bin eepro100_eeprom endif
It's sort of a rats nest all thrown together in one directory where you just happen to build the parts that apply to your board/ARCH.
I would like to propose a new scheme that fits in with your design goals. I see two fundamental ways that we might improve on this layout.
1) Make the examples directory be a sub-directory structure that allows a board-specific break-down beneath it.
2) Make a "diagnostics" (or "tools") sub-directory beneath each board directory if it can build tools in the style of the current "examples" directory.
Personally, I think 2) would be a cleaner distribution, though I am curious to know if you have any thoughts in this area too.
Thanks, jdl