[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJiQ=7CmFNhufdeoeH_6SuYOhf3Luwc2zwy_+8au1V8RW78rOw@mail.gmail.com>
Date: Mon, 17 Nov 2014 11:47:12 -0800
From: Kevin Cernekee <cernekee@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jonas Gorski <jogo@...nwrt.org>,
Ralf Baechle <ralf@...ux-mips.org>,
Florian Fainelli <f.fainelli@...il.com>,
Jon Fraser <jfraser@...adcom.com>,
Dmitry Torokhov <dtor@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 22/22] MIPS: Add multiplatform BMIPS target
On Mon, Nov 17, 2014 at 10:55 AM, Arnd Bergmann <arnd@...db.de> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists