Support for ClearFog GT 8K?

I followed the prompts at , but unfortunately I still can't start openwrt from my GT8K.
Any new developments about this device ?
And noticed that the relevant content in PR1646 may contain OEM information for @sduponch

Did you ever get this to run? Just ordered one for myself and would like to get it running with OpenWRT.

I have sold it because I cannot get the EIP197 firmware that requires the NDA protocol

Thank you for the information. Shame it didn't work out for you.
Marvell is really overdoing it with their NDA policy. So tough to get any sort of information about their products. Well guess I'll wait until the board gets here and see if I can get it running.

Apparently firmware with limited functionality was added to linux firmware repository:


So the ClearFog GT 8K finally made it to my home. I'm now working on getting OpenWRT to run on the device. I was able to compile everything and the image is booting from the sdcard.
I've added my changes to my GitHub.

However, when the image is up, I do not get the login to OpenWRT on the serial console. When using the failsafe mode it works as expected, but normal startup does not connect me to the OpenWRT CLI.

Has anyone encountered this behaviour before, and has an idea on how to fix it?

It got the desired behaviour by adding the line:
to the /etc/inittab file.
Not sure yet if it is desired that the console is not displayed by default or if I configured something wrong. The whole inittab now looks like this:

root@OpenWrt:/# cat /etc/inittab
::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K shutdown

On another note, the mini eip197 firmware as pointed to by @tmn505 - thanks again for highlighting this - seems to work. When enabling the Kernel Module:
Cryptographic API modules -> kmod-crypto-hw-safexcel
in compilation, I get the printout during startup:

[    9.325821] crypto-safexcel f2800000.crypto: EIP197:241(0)-HIA:230(2,6,6),PE:332,alg:7ffdf000
[    9.334914] crypto-safexcel f2800000.crypto: TRC init: 15360d,80a (48r,256h)

The crypto offload to hardware also seems to work, at least for a quick test with OpenSSL, the performance was not that impressive

time -v openssl speed -evp aes-128-cbc -elapsed
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     347896.76k   851035.22k  1266900.82k  1411924.31k  1499936.09k  1505072.47k

time -v openssl speed -evp aes-128-cbc -elapsed -engine devcrypto
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc        937.72k     3913.98k    15463.34k    56088.58k   282408.28k   399501.99k

I assume here that the constant context switches between user and kernel space are quite expensive. Additionally, all crypto interrupts are processed by one CPU only. Not sure what the cause for this is either, but for sure with an optimized solution / application, the hw offloading could come in handy.

Today I set about installing miniPCIe wifi modules. Sadly PCIe is not well supported at the moment. After some googling, I managed to apply a patch, which for sure is wrongly named and placed in the build tree, but enables support for PCIe. However, only 1 of the 3 miniPCIe ports is actually working. The other 2 are not up. I suspect this is due to an incomplete device tree which only actually initializes one PCIe interface. I've checked the simplified schematics and it seems to support my suspicion. I'll try to get the SolidRun Technical Support to check into this manner.

Check my comment here:
I Would say this PCIe patch won't be accepted.

Thanks for pointing this out. Definitely will have to check the u-boot again. And I fully agree, the patch like this is pointless.
At the very least it would have to be changed to only be applied when the Kernel is compiled for this board. Currently I have no clue how to do that in the OpenWRT build system.
For sure I would like to have the board support pulled to the official repository when everything is done, but I guess that will also need some more cleaning up, as I already messed up the commits when I tried to correct a file...
I've contacted SolidRun for support on the PCIe topic, mainly to get the other slots working, but I also mentioned this topic. So depending on how willing they are to assist here, I hope they can help solve this topic as well.

To report on progress - note as mPCIe cards, I use the Compex WLE900VX. The device tree is complete according to SolidRun. Their default configuration is:

  • 1 slot PCIe
  • 1 slot mSATA
  • 1 slot USB <- combined with a SIM card reader for LTE usage.

I was able to modify the *.dts in both u-boot and device kernel to change the mSATA slot to PCIe. It is properly detected in u-boot.
With the new u-boot, the Linux Kernel patch should not be necessary anymore to bring up the cards, but it is for the pre-configure PCIe slot, or the Compex card won't be detected. When checking in u-boot log, there actually is a no-link report for this slot.
However, when the kernel patch is enabled, the previously mSATA slot won't detect the Compex card.

So currently I have this weird situation where slot-0 is not working in u-boot, and slot-1 not working with the kernel patch needed to make slot-0 work. I did a hacky test where I will apply the kernel patch only to the first PCIe device polled (urgh), and that at least got both cards working in OpenWRT. But of course it is not a publishable solution...

SolidRun is able to reproduce the issue, but with other miniPCIe cards than the Compex ones it works fine. At the moment they are not able to support more on this issue.

@tmn505: I've now checked more specifically into issues with Compex cards in u-boot and stumbled upon this patchwork. There seem to be similar issues on the Turris Mox (Armada a3700 cpu), where there was some work done on the pcie driver. Maybe you have some related input, what did the trick for the a3700 driver?

These patches are already in mainline kernel and the author of those patches sent pull request to OpenWrt, but nobody cares about it.

These SoC have completely different PCIe driver and that series is unrelated, from the looks, the only related thing is Compex cards not detected when the reset signal is not triggered in kernel.

Can't say much about Armada 8040/ClearFog GT-8K, maybe additional changes to kernel dts are needed and U-Boot modification of MPP's to leave them for kernel to trigger reset? Don't know much, since I don't own this device.

Thank you both for your inputs. I'll try to discuss this further with SolidRun and see what their input on this is. Not sure if they are willing to invest more time, if the issue only affects the Compex cards.