This patch will be required for the ti814x series as that exposed this underlying issue. The problem goes like this. On OMAP3 there is reason (at least at first glance) for having both <asm/arch/hardware.h> and <asm/arch/cpu.h> in the config file as we reference values found in both in CONFIG options. am335x_evm.h started from one of these platforms (at least in some roundabout fashion) and didn't think twice since we also reference something that's more deeply included. Along comes ti814x support which sets in <asm/arch/omap.h> NON_SECURE_SRAM_START/END based on CONFIG selection and burries most of the real choices of <asm/arch/hardware.h> in a sub-include also based on CONFIG. The good news is that only <asm/arch-am33xx/omap.h> includes values we care about, based on CONFIG and in that one file we can not #include <config.h> and get away with this implicit include.
Without this, and making <asm/arch-am33xx/omap.h> #include <config.h> we get into a loop with CONFIG_SYS_BAUDRATE_TABLE being re-defined (which both am33xx boards ought to drop their local define of anyhow) but also CONFIG_FS_FAT _not_ being set as when we evaluate the fallbacks the first part of the test is not true. This means an alternate patch would be to re-order the config files such we add our #includes near the end, rather than front of the file.