Skip to content
Snippets Groups Projects
  1. Nov 07, 2021
  2. Nov 05, 2021
  3. Nov 04, 2021
  4. Nov 03, 2021
    • Tom Rini's avatar
      Merge https://source.denx.de/u-boot/custodians/u-boot-usb · bc18582a
      Tom Rini authored
      - usb: mtu3: flush cache for the first GPD when allocate GPD ring
      bc18582a
    • Tom Rini's avatar
      Merge https://source.denx.de/u-boot/custodians/u-boot-marvell · 0bf6563a
      Tom Rini authored
      - pci_mvebu: Fix access to config space and PCIe Root Port (Pali)
      - a37xx: pci: Program the data strobe for config read requests (Pali)
      - kwboot: Misc improvements and fixes (Pali)
      0bf6563a
    • Chunfeng Yun's avatar
      usb: mtu3: flush cache for the first GPD when allocate GPD ring · 2c4f2176
      Chunfeng Yun authored and Marek Vasut's avatar Marek Vasut committed
      
      When allocate the GPD ring, and tell its address to the controller, then
      the driver starts or resumes the QMU, the controller will try to access
      the first GPD, so need flush the first one to avoid wrong GPD status.
      
      Reported-by: default avatarXin Lin <Xin.Lin@mediatek.com>
      Signed-off-by: default avatarChunfeng Yun <chunfeng.yun@mediatek.com>
      2c4f2176
    • This contributor prefers not to receive mails's avatar
      arm: a37xx: pci: Program the data strobe for config read requests · 57fa6fb9
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      According to the Armada 3720 Functional Specification Data Strobe applies
      for both read and write config requests.
      
      Data strobe bits configure which bytes from the start address should be
      returned for read request. Set value 0xf (all 4 bits) into Data Strobe
      register to read all four bytes from specified 32-bit config space
      register. Same value for Data Strobe register is programmed by Linux
      pci-aardvark.c driver for config read requests.
      
      Without this patch pci-aardvark driver sets data strobe register only
      during config write operations. So any followup config read operations
      could result with just partial datai returned (if previous write operation
      was not 32-bit wide). This patch fixes it and ensures that config read
      operations always read all bytes from requested register.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      57fa6fb9
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Do not send magic seq when changing baudrate back to 115200 · 62a98f49
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      After successful transfer of whole image only two things can happen:
      - BootROM starts execution of data block, which changes UART baudrate
        back to 115200 Bd,
      - board crashes and causes CPU reset
      
      In both cases UART baudrate is reset to the default speed. So there is
      no need to send special magic sequence to inform kwboot that baudrate is
      going to be reset and kwboot does not need to wait for this event and
      can do it immediately after BootROM acknowledges end of xmodem transfer.
      
      Move ARM code for sending magic sequence from main baudrate change
      section to binhdr_pre section which is executed only before changing
      baudrate from the default value of 115200 Bd to some new value. Remove
      kwboot code waiting for magic sequence after successful xmodem transfer.
      
      Rationale: sometimes when using very high UART speeds, magic sequence is
      damaged and kwboot fails at this last stage. Removal of this magic
      sequence makes booting more stable.
      
      Data transfer protocol (xmodem) is using checksums and retransmit, so it
      already deals with possible errors on transfer line.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      62a98f49
Loading