lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [v3,11/41] mips: reuse asm-generic/barrier.h
On Wed, 27 Jan 2016, Ralf Baechle wrote:

> > So you need to build a different kernel for some types of MIPS systems?
>
> Yes. We can't really do without. Classic MIPS code is not relocatable
> without the complexity of PIC code as used by ELF DSOs - and their
> performanc penalty. Plus we have a number of architecture revisions
> ovr the decades, big and little endian, 32 and 64 bit as the major
> stumbling stones. There however are groups of similar systems that
> can share kernel binaries.

Matt (cc-ed) has recently posted patches to add support for a relocatable
kernel, implemented without the usual overhead of PIC code. It works by
retaining relocations in a fully-linked binary and then simply replaying
the work the static linker does when assigning addresses, as the image
loaded is copied to its intended destination at an early bootstrap stage.
See:
<http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1449137297-30464-1-git-send-email-matt.redfearn%40imgtec.com>
for details.

I think this framework can be reused by carefully choosing instructions
used in early bootstrap code, up to the relocation stage, so that it is
runnable anywhere (not the same as PIC!) like early ld.so initialisation
and then loading the whole attached image starting from an address where
RAM does exist on target hardware.

Endianness is a different matter, obviously we can't build a single image
for both, although for distributions' sake an approach similar to one used
with bi-endian firmware (for hardware which has an easy way to switch the
endianness, e.g. a physical jumper or a configuration bit stored in flash
memory; not to be confused with the reverse user endianness mode) might be
feasible, by glueing two kernel images together and then selecting the
right one early in bootstrap, perhaps again reusing Matt's framework.
I'm not sure if this is worth the effort though, I suspect the usage level
of this feature would be minimal.

All in all I think making a generic MIPS kernel just might be feasible,
but with the diversity of options available the effort required would be
enormous. NetBSD for example I believe supports building a kernel that
correctly runs on both R3000 (MIPS I, 32-bit) and R4000 (MIPS III, 64-bit)
DEC hardware (as did DEC Ultrix, the vendor OS for these systems). These
processors are different enough from each other that you cannot use the
same code for cache, memory and exception management in an OS kernel --
backward compatibility is only provided for user software. That proves
the concept, however in a very limited way only, not even covering SMP,
and their R4000 kernel does not support 64-bit userland I believe. They
still have completely separate ports for other MIPS hardware, such as for
Broadcom SiByte SB-1 (MIPS64r1) processors.

Maciej

\
 
 \ /
  Last update: 2016-01-27 13:21    [W:0.051 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site