Skip to content
Snippets Groups Projects
  1. Aug 12, 2024
  2. Aug 05, 2024
    • Ian Campbell's avatar
      Update appstream metadata · ecc0a4c8
      Ian Campbell authored
      Fixing issues highlighted by `appstream-cli validate`:
      
      ```
      W: org.linux-sunxi.sunxi-tools:3: cid-rdns-contains-hyphen org.linux-sunxi.sunxi-tools
      I: org.linux-sunxi.sunxi-tools:7: summary-first-word-not-capitalized
      I: org.linux-sunxi.sunxi-tools:20: url-not-secure http://linux-sunxi.org/Sunxi-tools
      E: org.linux-sunxi.sunxi-tools:~: desktop-app-launchable-missing
      I: org.linux-sunxi.sunxi-tools:~: content-rating-missing
      I: org.linux-sunxi.sunxi-tools:~: developer-info-missing
      
      ✘ Validation failed: errors: 1, warnings: 1, infos: 4, pedantic: 1
      ```
      ecc0a4c8
  3. Aug 04, 2024
  4. Jan 11, 2024
  5. Nov 21, 2023
    • Andre Przywara's avatar
      fel: add Allwinner A523 SoC support · 34573bfe
      Andre Przywara authored
      
      The Allwinner A523 has 128KiB of MCU0 SRAM, which the BootROM will not
      touch. The BROM will use some memory in SRAM A2, which it also clears
      upon entering FEL mode, starting from address 0x44000. The lowest
      allocation seems to be the IRQ stack growing down from 0x45400.
      So we won't touch any of that memory, but can freely use the full 128KB
      of the primary SRAM for payloads. This means we won't need to swap any
      buffers for preserving BROM stacks.
      We put the SPL thunk code just below 0x44000, to leave as much SRAM for
      the payload as possible.
      The rest of the SoC is pretty standard, although the watchdogs are now
      in separate MMIO frames, not part of some timer block anymore.
      
      The secure boot mode will prevent even reading the BootROM, so we can
      use an address in there to test for the secure boot state. However, even
      though a simple "smc #0" will return to its caller, the NS bit is still
      set, so we are still in non-secure state afterwards. So leave this bit
      out for now until we figure out how to switch to secure state properly.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      34573bfe
  6. Nov 03, 2023
    • Andre Przywara's avatar
      fel: sid: fix stack overflow while reading from SID · fcb78657
      Andre Przywara authored
      
      When reading from the SID device using the normal memory access method,
      we upload our "readl" routine (via fel_readl_n()), which expects a number
      of *words* to read. However length is given in *bytes*, so we read four
      times as much, and overflow our key buffer, clobbering the return address.
      This is typically fatal:
      ===============
      $ ./sunxi-fel sid
      02c05200:12345678:34567890:76543210
      Segmentation fault (core dumped)
      $
      ===============
      
      Fix this by giving the number of (32-bit) words instead. We already
      checked that length is a multiple of 4, so we can just divide.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      fcb78657
  7. Oct 25, 2023
    • Andre Przywara's avatar
      fel: add list-socs command · 91f9ccfc
      Andre Przywara authored
      
      As over time we gain support for more and more SoCs, it would be
      convenient to know which SoCs a particular build actually supports.
      
      Add a "list-socs" command, that just iterates over the soc_info table
      and outputs the SoC ID and the name for each entry.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      91f9ccfc
    • Andre Przywara's avatar
      fel: introduce get_next_soc() · 34c31508
      Andre Przywara authored
      
      At the moment we can search for a specific SoC in our supported SoC
      table by looking for its SoC ID, but we cannot otherwise enumerate all
      supported SoCs.
      
      Add a get_next_soc() function that allows iterating over our (internal)
      table: The first call will take NULL as an argument, subsequent calls
      pass in the pointer returned by the previous call. When we reach the end
      of the list, the function returns NULL.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      34c31508
  8. Oct 22, 2023
  9. Aug 20, 2023
  10. Aug 14, 2023
  11. Aug 12, 2023
  12. Aug 08, 2023
    • Andre Przywara's avatar
      fel: h616: support alternative die variant · 05f58b50
      Andre Przywara authored
      
      The Allwinner H616 ships in at least two die variants, sometime under a
      different name (H618, T507), but sometimes labeled as a normal "H616".
      The die variants differ in their CPU cluster control subsystem, which
      affects the location of the RVBAR shadow register used to reset the core
      into 64-bit mode. We use that in the "reset64" command, but also as part
      of the boot process using the "uboot" command, on ARMv8 cores.
      
      Add code to detect the die variant by reading the VER_REG MMIO register,
      where the original die reports 0x00 in the lower 8 bits, but the newer
      die variants apparently 0x02. In the latter case let the aw_rmr_request()
      function use the alternative RVBAR address to do the 64-bit switch.
      This matches what we do in U-Boot and Trusted Firmware.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      05f58b50
  13. Apr 11, 2023
    • Andre Przywara's avatar
      fel: sid: fix segfault with default section map · 6a2f6b5e
      Andre Przywara authored
      
      The generic_2k_sid_maps, describing the SID sections for chips where we
      don't have any specific information yet, was missing the terminating
      NULL section, so we would run off into to woods, beyond the array limit.
      This would most commonly result in a segfault:
      $ sunxi-fel sid-dump
      ....
                      00000000 00000000 00000000 00000000
      Segmentation fault (core dumped)
      =================
      
      Add the NULL sentinel to terminate the loop correctly.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      6a2f6b5e
  14. Mar 05, 2023
    • Andre Przywara's avatar
      fel: sid: add documentation · ed3039cd
      Andre Przywara authored
      
      The new sid-dump command was missing documentation. Add it to the
      internal usage() function as well as to the manpage.
      Clarify on the existing sid-registers command on the way, and add
      a stanza for the wdreset command.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      ed3039cd
    • Andre Przywara's avatar
      fel: sid: add SID dump maps for other SoCs · 536a1910
      Andre Przywara authored
      At the moment we only have a SID map for the R40. Add a generic
      placeholder map, covering the 2048 bits that most SoCs have (at least).
      
      The linux-sunxi Wiki page [1] for the SID register layout describes
      entries for the H6 and "SoCs before H6". Add those tables as well, and
      use the latter one for some SoCs which were released the closest to the
      H6 (H3, A64, H5).
      If people have more information, more specific maps can be added.
      
      [1] https://linux-sunxi.org/SID_Register_Guide#eFUSE_Region_Overview
      
      
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      536a1910
    • Andre Przywara's avatar
      fel: sid: unify SID functions into fel_read_sid() · 4a0c8c7e
      Andre Przywara authored
      
      At the moment we have two functions reading the SID eFuses:
      fel_get_sid_root_key() to read the "root key" (the first 128 bits), and
      fel_get_sid() to read an arbitrary range. The latter does not use the
      MMIO register workaround on affected SoCs, while the former only reads
      that specific range of bits.
      
      Unify the two functions into one that combines the advantanges of both:
      we can read any range of eFuses, and it uses the MMIO register access
      method, if needed. Switch the users to use the new function.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      4a0c8c7e
    • Andre Przywara's avatar
      fel: sid: extend assembly to dump arbitrary range · c1f947e0
      Andre Przywara authored
      
      To workaround a hardware erratum on the H3 SoC, we use an MMIO register
      based assembly routine to dump the SID registers, if needed. This is
      hard-coded to read the first four 32-bit words of the SID fuses.
      
      For the sid-dump command we need to access any arbitrary regions of the
      fuses, so extend the routine to take a start and an end address to dump.
      
      This changes the assembly source in the thunks/ directory:
      - We load the start address into r1, instead of zeroing it. The start
        address is put right after the SIO MMIO base address, at the end of
        the code.
      - When storing the read value into the result buffer, we automatically
        increase the pointer register (r3), instead of adding the offset
        address, since this is now no longer zero based.
      - To check for the end, we read the end pointer (stored at the end of
        the code, right after the offset), and compare against that instead of
        the hardcoded value of 16.
      This assembly file was put through the thunks Makefile, and the resulting
      content was copied from thunks/sid_read_root.h into fel_lib.c.
      
      For now we are still putting the constant values of 0 and 16 in, but
      this time from the C code.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      c1f947e0
  15. Feb 22, 2023
    • qianfan Zhao's avatar
      fel: Introduce 'sid-dump' · 056b65fb
      qianfan Zhao authored
      
      The sid memory maps are copied from allwinner 3.10 bsp.
      
      Next is a sample output from allwinner T3:
      $ sunxi-fel sid-dump
      chipid          1300000c 02c04700 79350400 30791acc
      in              00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      ssk             00000000 00000000 00000000 00000000
      thermal         0823081c
      ft_zone         00000000 00000000
      tvout           00ff02ad 00f8029e 00f0028d 00f902a2
      rssk            00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      hdcp_hash       00000000 00000000 00000000 00000000
      reserved        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
                      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
                      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
                      00000000 00000000 00000000 00000000
      
      Signed-off-by: default avatarqianfan Zhao <qianfanguijin@163.com>
      056b65fb
  16. Feb 03, 2023
  17. Jan 28, 2023
  18. Jan 08, 2023
  19. Dec 07, 2022
    • Andre Przywara's avatar
      uart0-helloworld-sdboot: add support for F1C100s · 530adfa1
      Andre Przywara authored
      
      The F1C100s series of SoCs has some subtle differences in its UART
      setup:
      - The UART is at a previously unused address.
      - The base clock is not APB2, but APB1.
      - The input clock is not 24 MHz, but CPU clock / 2 / 2.
      - The clock and reset gates are different bits at different addresses.
      
      Add support for all those differences, tied to the F1C100s SoC ID.
      
      Also change the GCC target architecture for uart0-helloworld-sdboot to
      ARMv5, since this is now the oldest support architecture revision.
      When the compiler defaulted to ARMv7, it was generating ubfx instructions,
      which were only introduced in ARMv6.
      
      Signed-off-by: default avatarAndre Przywara <osp@andrep.de>
      530adfa1
  20. Jul 29, 2022
Loading