1. 08 Aug, 2020 4 commits
    • Ecmel Berk Canlıer's avatar
      zte-axon7: Fix sector size, allow booting without microSD · da5a4405
      Ecmel Berk Canlıer authored
      (Also fixes swapped screen resolution settings)
    • Ecmel Berk Canlıer's avatar
      zte-axon7: Gets into Weston! · cd59527c
      Ecmel Berk Canlıer authored
      (well, on rootfs anyway, flashing boot/kernel should work fine)
      Run 'pmbootstrap export', and flash the zte-axon7.img into an microSD
      card. Then you can use 'pmbootstrap flasher boot' or 'pmbootstrap
      flasher flash_kernel'.
      The initramfs cannot find the subpartition labels when pmOS is flashed
      into the /system partition. I have no idea why.
    • Ecmel Berk Canlıer's avatar
      zte-axon7: Switch to downstream kernel · 35fb465a
      Ecmel Berk Canlıer authored
      The downstream kernel will actually start up until initramfs with a
      couple patches and gcc6.
      (gcc6 required for "Alignment fault" panics)
      Since the initramfs cannot find the subpartitions, the boot doesn't
      complete. However, debug-shell works and you can use telnet to view the
    • Ecmel Berk Canlıer's avatar
      zte-axon7: New device, WIP · 3ef1714c
      Ecmel Berk Canlıer authored
      linux-zte-axon7 exists but is unused, as linux-postmarketos-qcom-msm8996
      seems to have better potential (aka it doesn't immediately reboot into
      Booted using pmbootstrap flasher boot, the device will hang without any
      indication of progress (no USB, display is frozen), but it will not
      panic and reboot into EDL like it does with the downstream kernel.
      maximum-attention hook didn't work as far as I could tell.
      The kernel doesn't seem to be panicking, as no ramoops logs are present
      when rebooted into recovery.
      -- issues with linux-zte-axon7 --
      The downstream kernel panics due to some weirdness with the display:
      [    1.054753] proc_dir_entry 'driver/lcd_id' already registered
      Full ramoops log available at: https://ebc.li/h4qa
      I have tried a quick and dirty patch to ignore all registration calls
      after the first one, but doing that seems to just make the kernel panic
      elsewhere. Disabling the problematic module (CONFIG_ZTE_LCD_COMMON_FUNCTION)
      from the Kconfig will cause the same (or similar) panic, with the
      ramoops logs being available here:
      With ugly workaround: https://ebc.li/yahi
      With CONFIG_ZTE_LCD_COMMON_FUNCTION disabled: https://ebc.li/3fj5
  2. 06 Aug, 2020 2 commits
  3. 05 Aug, 2020 1 commit
  4. 04 Aug, 2020 2 commits
  5. 03 Aug, 2020 19 commits
  6. 02 Aug, 2020 2 commits
  7. 31 Jul, 2020 2 commits
  8. 30 Jul, 2020 4 commits
  9. 29 Jul, 2020 4 commits