Icenowy

I didn't blacklist NS1066 because my NS1066 HDD case doesn't report UAS at all (with Ivy Bridge PC's USB3).
 
P.S. NS106X will only report UAS at USB3 ports.

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?)

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?)

`SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612]` is tested to work.

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?)

`SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612]` is tested to work.

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?)

@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.

@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 .

@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.

H6 has hardware virtualization, and now with mainline kernel it's possible to run KVM on it.
 
For Xen, it's possible to port, but I don't know who wants to port ;-)

H6 has hardware virtualization, and now with mainline kernel it's possible to run KVM on it.
 
For Xen, it's possible to port, but I don't know who wants to port ;-)

@martinayotte sun50i-h6-emac is already gone dropped in the newest driver, and upstream DT now uses
```
            compatible = "allwinner,sun50i-h6-emac",
                     "allwinner,sun50i-a64-emac";
```
 
If someone needs me to do hack on OPi3, I can consider to purchase one. Shipment from Shenzhen to Guangzhou (where I live) usually cost <24h.

@martinayotte I remember in mainline Linuc I killed sun50i-h6-emac in driver, and it only exists as a fallback compatible string.

I'm not sure, my distro uses 4.19 and omitted 4.18.

Mikey from Sinovoip showed me some photos on kernel logs that is said to be booting A40i with mainline U-Boot.
 
(Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip ;-) )

Mikey from Sinovoip showed me some photos on kernel logs that is said to be booting A40i with mainline U-Boot.
 
(Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip ;-) )

BTW (off topic of this post) the NS1068 quirk in kernel cmdline can be dropped now, as it's mainlined by me.
 
NS1066 one should still be kept as I didn't get a quirky NS1066 (my NS1066 just doesn't announce UAS).

Thanks to help from Jernej, the magenta display issue is solved in U-Boot commit 79405999d7ee43f830825751b200d739b53f20f5 ("video: sunxi: de2/3: clear all BLD address space").

Thanks to help from Jernej, the magenta display issue is solved in U-Boot commit 79405999d7ee43f830825751b200d739b53f20f5 ("video: sunxi: de2/3: clear all BLD address space").

1.16V is beyond the recommended operation range, so I didn't add it now.
 
BTW H6 comes with two official DVFS table judged by "speed bin", maybe this needs to be implemented. ("Speed bin" info is in SID)

I didn't blacklist NS1066 because my NS1066 HDD case doesn't report UAS at all (with Ivy Bridge PC's USB3).
 
P.S. NS106X will only report UAS at USB3 ports.

A 4.9 kernel is released by Allwinner yesterday (as UTC+8).
 
P.S. AXP805 has only power key (for power down functionality) and DCDC+LDO, like RK805 from RK(used with RK3328, also OTT):-)

A 4.9 kernel is released by Allwinner yesterday (as UTC+8).
 
P.S. AXP805 has only power key (for power down functionality) and DCDC+LDO, like RK805 from RK(used with RK3328, also OTT):-)

No USB3/PCIE. This makes this board not interesting at all. I think people should wait for Orange Pi 3 (I think 3 Plus may also have also some problem) or Pine H64.
 
P.S. The DRAM chip is branded "Allwinner". (noted by TL Lim)