1. 10 10月, 2013 1 次提交
    • P
      mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN · 40462e54
      Paul Burton 提交于
      Linux modified the MTD driver interface in commit edbc4540 (with the
      same name as this commit). The effect is that calls to mtd_read will
      not return -EUCLEAN if the number of ECC-corrected bit errors is below
      a certain threshold, which defaults to the strength of the ECC. This
      allows -EUCLEAN to stop indicating "some bits were corrected" and begin
      indicating "a large number of bits were corrected, the data held in
      this region of flash may be lost soon". UBI makes use of this and when
      -EUCLEAN is returned from mtd_read it will move data to another block
      of flash. Without adopting this interface change UBI on U-boot attempts
      to move data between blocks every time a single bit is corrected using
      the ECC, which is a very common occurance on some devices.
      
      For some devices where bit errors are common enough, UBI can get stuck
      constantly moving data around because each block it attempts to use has
      a single bit error. This condition is hit when wear_leveling_worker
      attempts to move data from one PEB to another in response to an
      -EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
      called to perform the data copy, and after the data is written it is
      read back to check its validity. If that read returns UBI_IO_BITFLIPS
      (in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
      wear_leveling worker, which then proceeds to schedule the destination
      PEB for erasure. This leads to erase_worker running on the PEB, and
      following a successful erase wear_leveling_worker is called which
      begins this whole cycle all over again. The end result is that (without
      UBI debug output enabled) the boot appears to simply hang whilst in
      reality U-boot busily works away at destroying a block of the NAND
      flash. Debug output from this situation:
      
        UBI DBG: ensure_wear_leveling: schedule scrubbing
        UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
        UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
        UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
        UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
        UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
        UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
        UBI: fixable bit-flip detected at PEB 1027
        UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
        UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
        UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
        UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
        UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
        UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
        UBI: fixable bit-flip detected at PEB 4083
        UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
        UBI DBG: erase_worker: erase PEB 4083 EC 55
        UBI DBG: sync_erase: erase PEB 4083, old EC 55
        UBI DBG: do_sync_erase: erase PEB 4083
        UBI DBG: sync_erase: erased PEB 4083, new EC 56
        UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
        UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
        UBI DBG: ensure_wear_leveling: schedule scrubbing
        UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
        ...
      
      This patch adopts the interface change as in Linux commit edbc4540 in
      order to avoid such situations. Given that none of the drivers under
      drivers/mtd return -EUCLEAN, this should only affect those using
      software ECC. I have tested that it works on a board which is
      currently out of tree, but which I hope to be able to begin
      upstreaming soon.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: NStefan Roese <sr@denx.de>
      40462e54
  2. 08 10月, 2013 1 次提交
    • W
      Fix number base handling of "load" command · b770e88a
      Wolfgang Denk 提交于
      As documented, almost all U-Boot commands expect numbers to be entered
      in hexadecimal input format. (Exception: for historical reasons, the
      "sleep" command takes its argument in decimal input format.)
      
      This rule was broken for the "load" command; for details please see
      especially commits 045fa1e1 "fs: add filesystem switch libary,
      implement ls and fsload commands" and 3f83c87e "fs: fix number base
      behaviour change in fatload/ext*load".  In the result, the load
      command would always require an explicit "0x" prefix for regular
      (i. e. base 16 formatted) input.
      
      Change this to use the standard notation of base 16 input format.
      While strictly speaking this is a change of the user interface, we
      hope that it will not cause trouble.  Stephen Warren comments (see
      [1]):
      
              I suppose you can change the behaviour if you want; anyone
              writing "0x..." for their values presumably won't be
              affected, and if people really do assume all values in U-Boot
              are in hex, presumably nobody currently relies upon using
              non-prefixed values with the generic load command, since it
              doesn't work like that right now.
      
      [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/171172Acked-by: NTom Rini <trini@ti.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NWolfgang Denk <wd@denx.de>
      b770e88a
  3. 07 10月, 2013 6 次提交
  4. 05 10月, 2013 1 次提交
  5. 04 10月, 2013 7 次提交
    • A
      ARM: VExpress: enable ARMv7 virt support for VExpress A15 · e261c83a
      Andre Przywara 提交于
      To enable hypervisors utilizing the ARMv7 virtualization extension
      on the Versatile Express board with the A15 core tile, we add the
      required configuration variable.
      Also we define the board specific smp_set_cpu_boot_addr() function to
      set the start address for secondary cores in the VExpress specific
      manner.
      There is no need to provide a custom smp_waitloop() function here.
      
      This also serves as an example for what to do when adding support for
      new boards.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      e261c83a
    • A
      ARM: extend non-secure switch to also go into HYP mode · d4296887
      Andre Przywara 提交于
      For the KVM and XEN hypervisors to be usable, we need to enter the
      kernel in HYP mode. Now that we already are in non-secure state,
      HYP mode switching is within short reach.
      
      While doing the non-secure switch, we have to enable the HVC
      instruction and setup the HYP mode HVBAR (while still secure).
      
      The actual switch is done by dropping back from a HYP mode handler
      without actually leaving HYP mode, so we introduce a new handler
      routine in our new secure exception vector table.
      
      In the assembly switching routine we save and restore the banked LR
      and SP registers around the hypercall to do the actual HYP mode
      switch.
      
      The C routine first checks whether we are in HYP mode already and
      also whether the virtualization extensions are available. It also
      checks whether the HYP mode switch was finally successful.
      The bootm command part only calls the new function after the
      non-secure switch.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      d4296887
    • A
      ARM: add SMP support for non-secure switch · ba6a1698
      Andre Przywara 提交于
      Currently the non-secure switch is only done for the boot processor.
      To enable full SMP support, we have to switch all secondary cores
      into non-secure state also.
      
      So we add an entry point for secondary CPUs coming out of low-power
      state and make sure we put them into WFI again after having switched
      to non-secure state.
      For this we acknowledge and EOI the wake-up IPI, then go into WFI.
      Once being kicked out of it later, we sanity check that the start
      address has actually been changed (since another attempt to switch
      to non-secure would block the core) and jump to the new address.
      
      The actual CPU kick is done by sending an inter-processor interrupt
      via the GIC to all CPU interfaces except the requesting processor.
      The secondary cores will then setup their respective GIC CPU
      interface.
      While this approach is pretty universal across several ARMv7 boards,
      we make this function weak in case someone needs to tweak this for
      a specific board.
      
      The way of setting the secondary's start address is board specific,
      but mostly different only in the actual SMP pen address, so we also
      provide a weak default implementation and just depend on the proper
      address to be set in the config file.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      ba6a1698
    • A
      ARM: trigger non-secure state switch during bootm execution · bb975455
      Andre Przywara 提交于
      To actually trigger the non-secure switch we just implemented, call
      the switching routine from within the bootm command implementation.
      This way we automatically enable this feature without further user
      intervention.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      bb975455
    • A
      ARM: add C function to switch to non-secure state · 1ef92385
      Andre Przywara 提交于
      The core specific part of the work is done in the assembly routine
      in nonsec_virt.S, introduced with the previous patch, but for the full
      glory we need to setup the GIC distributor interface once for the
      whole system, which is done in C here.
      The routine is placed in arch/arm/cpu/armv7 to allow easy access from
      other ARMv7 boards.
      
      We check the availability of the security extensions first.
      
      Since we need a safe way to access the GIC, we use the PERIPHBASE
      registers on Cortex-A15 and A7 CPUs and do some sanity checks.
      Boards not implementing the CBAR can override this value via a
      configuration file variable.
      
      Then we actually do the GIC enablement:
      a) enable the GIC distributor, both for non-secure and secure state
         (GICD_CTLR[1:0] = 11b)
      b) allow all interrupts to be handled from non-secure state
         (GICD_IGROUPRn = 0xFFFFFFFF)
      
      The core specific GIC setup is then done in the assembly routine.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      1ef92385
    • A
      ARM: add assembly routine to switch to non-secure state · 16212b59
      Andre Przywara 提交于
      While actually switching to non-secure state is one thing, another
      part of this process is to make sure that we still have full access
      to the interrupt controller (GIC).
      The GIC is fully aware of secure vs. non-secure state, some
      registers are banked, others may be configured to be accessible from
      secure state only.
      To be as generic as possible, we get the GIC memory mapped address
      based on the PERIPHBASE value in the CBAR register. Since this
      register is not architecturally defined, we check the MIDR before to
      be from an A15 or A7.
      For CPUs not having the CBAR or boards with wrong information herein
      we allow providing the base address as a configuration variable.
      
      Now that we know the GIC address, we:
      a) allow private interrupts to be delivered to the core
         (GICD_IGROUPR0 = 0xFFFFFFFF)
      b) enable the CPU interface (GICC_CTLR[0] = 1)
      c) set the priority filter to allow non-secure interrupts
         (GICC_PMR = 0xFF)
      
      Also we allow access to all coprocessor interfaces from non-secure
      state by writing the appropriate bits in the NSACR register.
      
      The generic timer base frequency register is only accessible from
      secure state, so we have to program it now. Actually this should be
      done from primary firmware before, but some boards seems to omit
      this, so if needed we do this here with a board specific value.
      The Versatile Express board does not need this, so we remove the
      frequency from the configuration file here.
      
      After having switched to non-secure state, we also enable the
      non-secure GIC CPU interface, since this register is banked.
      
      Since we need to call this routine also directly from the smp_pen
      later (where we don't have any stack), we can only use caller saved
      registers r0-r3 and r12 to not mess with the compiler.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      16212b59
    • A
      ARM: add secure monitor handler to switch to non-secure state · 45b940d6
      Andre Przywara 提交于
      A prerequisite for using virtualization is to be in HYP mode, which
      requires the CPU to be in non-secure state first.
      Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine
      which switches the CPU to non-secure state by setting the NS and
      associated bits.
      According to the ARM architecture reference manual this should not be
      done in SVC mode, so we have to setup a SMC handler for this.
      We create a new vector table to avoid interference with other boards.
      The MVBAR register will be programmed later just before the smc call.
      Signed-off-by: NAndre Przywara <andre.przywara@linaro.org>
      45b940d6
  6. 03 10月, 2013 2 次提交
  7. 02 10月, 2013 6 次提交
  8. 27 9月, 2013 7 次提交
  9. 24 9月, 2013 9 次提交