2010-09-26 18:13:43 board file structure suggestion
Rob Maris (GERMANY)
Over time, I'm going to get more aware of significance of board file maintenance when kernel development advances while any developer uses own boardfiles, or in my case: boardfile of bluetechnix tcm-bf537. The ADI team takes care of boardfile updates of all stuff that is in the vendors/AnalogDevices directory. It is my experience, that bluetechnix boardfiles are not updated with kernel updates. Okay, if one is monitoring the changes in AnalogDevices boardfiles over time, maintaining own boardfiles is not that problematic. But I'd suggest another approach, just like some major kernel decisions in the past, where e.g. growing diversities in any field led to changes in architecture.
Board files should be splitted in chip files and peripheral files. The chip files only contain the SoC resources which do not change as per MCU type/derivative, while a peripheral file, which can still be named boardfile only describes resources beyond the chip level. Of course, the problem lies in structs that contain elements from both "worlds" - the on-chip peripherals and the off-chip peripherals. This could be solved by a script that constructs a compound C-source file. I'd also consider it as practical, when all off chip resources are defined in resource-specific files, like components in e PCB-layout system that are imported, and here: included in the board file.
Up to this point this is rough brainstorming. Let me first wait for responses prior to generating more text. One remark: at least I'd wish to have all board files sorted according to on-chip and off-chip resources for each section.
2010-09-26 19:29:37 Re: board file structure suggestion
Mike Frysinger (UNITED STATES)
in practice, it doesnt really work. the pin selection for the EMAC/UART/SPORT may differ greatly between boards.