[U-Boot-Users] Diagnostic Tools in U-Boot
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
In message 1104876780.23236.46.camel@cashmere.sps.mot.com you wrote:
I have a few board-specific tools that help with some board diagnostics and manufacturing processes. These
You're not the first one...
tools are currently built in the "examples" directory, but are highly board-specific. (EEPROM programming, memory checking, Serial Number stamping, etc.)
I always thought the name "examples" was clear enough. This is NOT a place for general purpose code, especially not for borad-dependent code.
Currently, the examples directory has board-specific binaries that it builds, but it does so based on the the ARCH variable, like this:
This may be inelegant or even ugly, but i IMHO ok for the simple examples.
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.
ARCH yes, board no.
I would like to propose a new scheme that fits in with
Why a new scheme instead of simply using what's already in place and being used by others?
- Make the examples directory be a sub-directory structure that allows a board-specific break-down beneath it.
No. "examples" means example code, and to be more specific: examples for standalone programs. Board dependent code belongs to board directories.
- Make a "diagnostics" (or "tools") sub-directory beneath each board directory if it can build tools in the style of the current "examples" directory.
If you really feel you must create a sub-directory in your board directories feel free to do this. To me it makes little sense, though.
Personally, I think 2) would be a cleaner distribution, though I am curious to know if you have any thoughts in this area too.
For example, have a look at the board/trab directory; the Makefile there includes rules to build a custom tool "trab_fkt" which is used by the board manufacturer for burn-in tests. This is totally transpa- rent to the rest of the U-Boot tree.
Feel free to do something similar. I see no real need for a new level of directories.
Best regards,
Wolfgang Denk
participants (2)
-
Jon Loeliger -
Wolfgang Denk