Icenowy

Members
  • Content Count

    50
  • Joined

  • Last visited

1 Follower

About Icenowy

  • Rank
    Advanced Member

Recent Profile Visitors

1317 profile views
  1. `SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612]` is tested to work.
  2. oh I don't think the previous word will work. RTW88 driver only uses the BAR with ID 2, which is the memory space, not IO space.
  3. Interestingly the wireless card also uses IO space... could you try to add `num-viewport = <4>;` to the PCIe device node and remove calls for dw_pcie_prog_outbound_atu() in sunxi_pcie_host_init() ? (although I don't know whether this will work...)
  4. Currently it's tested on Pine H64 model A. More tests, e.g. on OPi 3 is welcomed. (And if a PR can be sent, it's better :-) )
  5. As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration. However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space. Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working. The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000. A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped . In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works. Contributions to the hypervisor is welcomed. (In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)
  6. @Igor I found why anx6345 mainlined in 5.5 doesn't work on TERES-I. https://github.com/Icenowy/linux/commit/e20b4f7fade6a7305599aa8e279c013c3144226b an overflow bug.
  7. The keyboard loads a updater, then after a small time span it unloads the updater and loads the real keyboard. U-Boot can only recognize the updater.
  8. My U-Boot is not dark, but this kernel should have peoper KMS support for TERES.
  9. @Igor If you want to support 5.4 now, you can cherry-pick patches from https://github.com/AOSC-Dev/linux/tree/aosc-sunxi64-5.4.y , this currently works.
  10. I took out my own TERES-I and now debugging... A weird experience. ANX bridge and panel are recognized, but nothing is displayed.
  11. @Igor seems that you are at a 5.6 base now. Thus try my patches on 5.6? https://github.com/Icenowy/linux/commit/8df6da42f1244573edd3d22d39dbe8fc66a01cbd This fixes supply name issue for anx6345, should fixes TERES https://github.com/Icenowy/linux/commit/b68d225323c9a479b26ee22a2cb4bf4eefe13cc5 This adds ANX6345 node to Pinebook.
  12. @Igor @jernej I had a headache night to debug on ANX6345 on 5.6-rc1. The polarity of the reset pin in the DT should be reversed with the mainlined driver, compared to my first version. 5.4 should not be affected by this because the DT binding enters at 5.5 and the real driver at 5.6 .
  13. @blastiko I must tell you that 2Gbit = 256MByte. Memory chips are usually identified with Gbit as unit, not GByte.
  14. Recently I borrowed my Orange Pi PC2 to a friend, and he fails to set up SSH connection w/ it. After debugging w/ HDMI monitor, I found ssh_host_ecdsa_key, ssh_host_ed25519_key and ssh_host_rsa_key are preloaded to the Orange Pi PC2 image, which prevented SSH from working. Even if it doesn't prevent working of SSHD, it's also a severe security hole -- that means all Armbian installation with the same image will uses the same host key and they're vulnerable to MITM attack. I think these files should be purged when generating image, and regenerated when first powerup. It's what AOSC OS images do.
  15. @martinayotteI think many board DO explicitly provide the bus-width. Of course, I think many people haven't equipped ECC brain like me, so there could be some boards w/o bus-width. You can submit patches for mainline for those boards. The mainline doesn't agree to add bus-width to SoC DTSI because it's for the board's designer to decide the bus-width (of course it cannot go beyond the controller's maximum). For example, some board uses a SD card slot (which is bus-width = <4>) on a eMMC controller (which can be at most bus-width = <8>), and in this case the 4 remaining data lines can even be used as GPIO.