linux-kernel - Re: [PATCH V2 22/22] MIPS: Add multiplatform BMIPS target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Nov 2014 09:19:17 -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 8:13 AM, Arnd Bergmann <arnd@...db.de> wrote:
> This is not just DT, it's actually an implementation of a boot
> interface. The situation here seems much more to what we had on
> PowerPC a long time ago than what we had on ARM before the DT
> conversion. I think the best approach here would be to move the
> platform specific bits into the decompressor code, and allow
> multiple implementations of that. This way you can have the
> generic vmlinux file that has a common DT parser, and you wrap
> that into one decompressor per platform, some of which can have
> their own board detection logic or pre-boot setup where necessary.
>
> To be honest, I think having multiple DT files linked into the
> kernel is a really bad idea, because it doesn't solve the
> scalability problem at all. What we did on ARM was to force those
> hacks out into external projects such as the PXA impedence
> matcher [https://github.com/zonque/pxa-impedance-matcher]. This
> can handle all weird boot protocol and adapt them to the normal
> well-defined interfaces we have in the kernel.

To some extent this is how BCM3384 was done[1].

There is a tradeoff here: to add support for the older platforms it is
easy to build a new DTB file into the kernel image, but it is a lot of
trouble to write a new 3rd stage bootloader.  Do we want to maximize
our list of supported boards, or are we shooting for a super clean
kernel implementation right off the bat?

>> 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.


[1] https://github.com/Broadcom/aeolus
--
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/