1. 29 8月, 2017 1 次提交
  2. 11 7月, 2017 1 次提交
  3. 28 6月, 2017 1 次提交
  4. 07 10月, 2016 2 次提交
    • P
      MIPS: generic: Convert SEAD-3 to a generic board · 3f5f0a44
      Paul Burton 提交于
      Convert the MIPS SEAD-3 board support to be a generic board, supported
      by generic kernels.
      
      Because the SEAD-3 boot protocol was defined long ago and we don't want
      to force a switch to the UHI protocol, SEAD-3 is added as a legacy board
      which is detected by reading the REVISION register. This may technically
      not be a valid memory read & future work will include attempting to
      handle that gracefully. In practice since SEAD-3 is the only legacy
      board supported by the generic kernel so far the read will only happen
      on SEAD-3 boards, and even once Malta is converted the same REVISION
      register exists there too. Other boards such as Boston, Ci20 & Ci40 will
      use the UHI boot protocol & thus not run any of the legacy board detect
      functions.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14354/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3f5f0a44
    • P
      MIPS: generic: Introduce generic DT-based board support · eed0eabd
      Paul Burton 提交于
      Introduce a "generic" platform, which aims to be board-agnostic by
      making use of device trees passed by the boot protocol defined in the
      MIPS UHI (Universal Hosting Interface) specification. Provision is made
      for supporting boards which use a legacy boot protocol that can't be
      changed, but adding support for such boards or any others is left to
      followon patches.
      
      Right now the built kernels expect to be loaded to 0x80100000, ie. in
      kseg0. This is fine for the vast majority of MIPS platforms, but
      nevertheless it would be good to remove this limitation in the future by
      mapping the kernel via the TLB such that it can be loaded anywhere & map
      itself appropriately.
      
      Configuration is handled by dynamically generating configs using
      scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
      makes use of it. This allows for variations upon the configuration, eg.
      differing architecture revisions or subsets of driver support for
      differing boards, to be handled without having a large number of
      defconfig files.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      eed0eabd