[coreboot] [RFC]Static testing of our tree

[Patrick Georgi]

Am 07.11.2010 05:49, schrieb Stefan Reinauer:
>> I don't propose to do this now - that would mean that the autobuilder
>> reports errors for the next couple of weeks, but once we got the tree in
>> shape that it passes the test of the script, it could go in and make
>> sure that this issue doesn't come up again.
> Please, if anyone can help with the task of cleaning this up so we can
> add the check earlier, go ahead! It's a great way of improving coreboot
> without having to know too much about hardware details!
I improved the script to be location independent and to avoid a couple
of false positives (GPIO_DEV used to match FOO_GPIO_DEV).

The current list is:
CK804_MB_SETUP is defined in mainboard(s) and used elsewhere
DEFAULT_RCBA is defined in mainboard(s) and used elsewhere
DEVPRES1_CONFIG is defined in mainboard(s) and used elsewhere
DEVPRES_CONFIG is defined in mainboard(s) and used elsewhere
DIMM0 is defined in mainboard(s) and used elsewhere
DIMM1 is defined in mainboard(s) and used elsewhere
DIMM_MAP_LOGICAL is defined in mainboard(s) and used elsewhere
DQS_TRAIN_DEBUG is defined in mainboard(s) and used elsewhere
FIRST_CPU is defined in mainboard(s) and used elsewhere
IA32_PERF_STS is defined in mainboard(s) and used elsewhere
K8_ALLOCATE_IO_RANGE is defined in mainboard(s) and used elsewhere
K8_REV_F_SUPPORT_F0_F1_WORKAROUND is defined in mainboard(s) and used
elsewhere
MCP55_MB_SETUP is defined in mainboard(s) and used elsewhere
MCP55_PCI_E_X_0 is defined in mainboard(s) and used elsewhere
MCP55_PCI_E_X_1 is defined in mainboard(s) and used elsewhere
PAYLOAD_IS_SEABIOS is defined in mainboard(s) and used elsewhere
PLLMSRhi is defined in mainboard(s) and used elsewhere
PLLMSRlo is defined in mainboard(s) and used elsewhere
RCBA is defined in mainboard(s) and used elsewhere
RES_DEBUG is defined in mainboard(s) and used elsewhere
SATA_MAP is defined in mainboard(s) and used elsewhere
SB_VFSMAF is defined in mainboard(s) and used elsewhere
SECOND_CPU is defined in mainboard(s) and used elsewhere
SET_NB_CFG_54 is defined in mainboard(s) and used elsewhere
SYSTEM_TYPE is defined in mainboard(s) and used elsewhere
TOTAL_CPUS is defined in mainboard(s) and used elsewhere
UART_DLL is defined in mainboard(s) and used elsewhere
UART_DLM is defined in mainboard(s) and used elsewhere
UART_FCR is defined in mainboard(s) and used elsewhere
UART_IER is defined in mainboard(s) and used elsewhere
UART_IIR is defined in mainboard(s) and used elsewhere
UART_LCR is defined in mainboard(s) and used elsewhere
UART_LSR is defined in mainboard(s) and used elsewhere
UART_MCR is defined in mainboard(s) and used elsewhere
UART_MSR is defined in mainboard(s) and used elsewhere
UART_RBR is defined in mainboard(s) and used elsewhere
UART_SCR is defined in mainboard(s) and used elsewhere
UART_TBR is defined in mainboard(s) and used elsewhere
USE_COM1 is defined in mainboard(s) and used elsewhere
USE_COM2 is defined in mainboard(s) and used elsewhere
USE_VCP is defined in mainboard(s) and used elsewhere
gCom1Base is defined in mainboard(s) and used elsewhere
gCom2Base is defined in mainboard(s) and used elsewhere

(in a tree with the SET_FIDVID patch, so that group is already taken
care of)

>> It's init_cpus.c, by the way ;-)
> This kind of stuff has been nasty ever since we were able to write RAM
> init in C. And the small differences in the variants make the code
> incredibly hard to maintain. Why does romstage.c have to cope with
> init_cpus.c at all... CONFIG_CPU_AMD_K8 should let Makefile.inc
> somewhere under the cpu/ directory know that we want this. Not each
> individual mainboard.
That's part romcc, part newconfig legacy.
With romcc the intuitive way was to include .c-files at a central place,
and the build system was painful enough that no-one bothered to try to
autogenerate that central place from higher level data.

Once we have the config stuff nailed down, the only issue with romcc is
the order of the files - if we'd get function prototype support in
romcc, that would simplify that step a lot.
>From a quick glance it seems that romcc immediately flattens functions
as they come in and thus requires all functions to be present that are
used at that point, so that won't be a simple change.

I think we can live without that change.

> That said, can we use the Makefile.inc file lists to fake #include
> statements for romcc? This way we could get rid of the annoyance for
> non-CAR boards, too. I wonder how complicated it would be to keep the
> order intact so romcc does not choke. Maybe we can also fix/enhance
> romcc to be a bit nicer to us...?
I intend to work on that once CAR boards are done, so the order is:
- remove the #define config mechanism
- remove #include *.c from CAR romstages
- remove #include *.c from romcc romstages

>> External tools, such as lint, splint could also be added into that
>> framework, should they be actually useful for our code (many aren't
>> because of their assumptions on C coding within OS environments).
> Should we go ahead and enable scan-build? It suffers from the same
> problems, and it makes the build incredibly slow, but some of the stuff
> it finds sure is interesting. (Maybe we should just manually run it and
> post the results somewhere on qa.coreboot.org if people are interested
> in fixing this stuff?
Maybe a periodic run (every 10 revisions), similar to how doxygen is
handled? But that only makes sense if someone is actually interested in
taking them on.


Patrick