hi chewitt
to obtain this result we studied the flow a lot and understood that, for example, the driver used a custom implementation for the encryption protocols, when in reality the chip can do it at the hardware level/using the kernel routines.
Therefore a lot of code incompatible with the mainline kernel has been removed and porting has become easier.
But we worked on what we had (rockchip) so the custom code for amlogic was removed because we couldn't test it.
The original driver has different behaviors for amlogic, and the error you receive is related to how the mac address is retrieved (rockchip read efuse .. amlogic seems to use static uboot parameter)
Clearly having an amlogic box would be more useful, and I thank you for the proposal.
But I do it in my little free time and I would not like to promise something that I cannot keep.