On Mon, Nov 17, 2014 at 10:55 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> And unless there is one, having a >> >> multiplatform kernel does not make much sense, as there is no sane way >> >> to tell apart different platforms on boot. >> > >> > How do you normally tell boards apart on MIPS when you don't use DT? >> >> On BCM7xxx (STB) kernels, we could assume the chip ID was in a known >> register, and also we could call back into the bootloader to get a >> somewhat-accurate board name. >> >> On BCM63xx there is logic in arch/mips/bcm63xx/cpu.c to try to guess >> the chip identity from the CPU type/revision (because the latter can >> be read directly from CP0). >> >> These systems were never really designed to support multiplatform >> kernels. The ARM BCM7xxx variants, by contrast, were. > > Guessing the chip doesn't really help you all that much of course > as long as you don't know the board, and once you know that, > the chip is implied. This mostly depends on the desired feature set, and the delta from one board to the next. Many of the reference board sections are largely copied from a working design, but sometimes there are changes that affect us. Other times there are tweaks that can be autodetected, like a different flash chip. The analog interfaces like SATA/USB/Ethernet don't tend to vary all that much (although some may be missing ports on the board, or disabled on the chip). The pin muxing situation leaves a lot of room for board differences, and on these platforms it isn't really handled in a central place. This gets even more challenging when combined with some of the power management requirements. The peripherals that I added in my patch submission are among the easiest / safest of the bunch. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
