I followed the prompts at https://github.com/openwrt/openwrt/pull/1646 , 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: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=eefb5f7410150c00d0ab5c41c5d817ae9bf449b3
2 Likes
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:
ttyS0::askfirst:/usr/libexec/login.sh
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
ttyS0::askfirst:/usr/libexec/login.sh
::askconsole:/usr/libexec/login.sh
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: https://github.com/openwrt/openwrt/pull/1646/files#r310205010
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.
Reviving this thread, @Skeletor, your patches still work for the mainline. Are you planning a PR with them? I realize the pcie modification might not work as you desire, but I have your patches applied to the head of openwrt and they work. If you are not interested in a PR I am interested in trying.
Recently there has also been some activity in the solid run forum about this (https://community.solid-run.com/t/booting-openwrt-on-clearfog-gt8k/313/9). Not sure if you are the same guy, if yes - sorry for not responding earlier, if no - might be worth combining the efforts.
Either way, glad to hear the patches work for you. Feel free to go ahead with the PR if you are up to it. I was intending to do it when I resumed work on the Clearfog this year, but I currently don't seem to be able to find the time to put everything together. If you can manage it would be great to get this merged.
Concerning the PCIe modifications: I managed to get this working as intended now (only device tree patches necessary). The issue was the used configuration for the Arm Trusted Firmware build. The Clearfog GT8K build instructions point to the macchiatobin configuration, however this one doesn't reset both PCIe slots properly.
I would assume you are not interested in using 2 PCIe slots, so I would suggest for the PR to use the standard (1xPCIe + 1xSATA) configuration. That should limit the changes to configuration files which would make for a nice and simple PR.
The information for how to get 2xPCIe working can be added to a wiki page or something once the PR is accepted by the community.
Hi, where can I find this info?
Currently on my hard drive at home, I didn't push them to any git repository 
I can provide the patches once I get back and have time to put the patchwork together.
Basically you need to:
- Modify DTS in u-boot to switch the currently used as SATA SERDES lane to PCIe
- Modify ATF source code (add PCIe initialization code for Clearfog GT8K for both PCIe slots
- Modify DTS in kernel to switch the currently used as SATA SERDES lane to PCIe
I've had some troubles with newer ATF / u-boot versions (Marvell doesn't seem to properly maintain the ARMADA CPU range anymore), so I stuck to the ones from the Solid Run build instructions (https://solidrun.atlassian.net/wiki/spaces/developer/pages/287178828/A8040+U-Boot).
Note that the ATF build configuration a80x0_mcbin, initializes 1 PCIe slot properly so it serves as a good starting point.
Same guy, no worries on response times 
I have had this board far too long for it not to be used. So I am motivated.
@mrbojangles: Saw you created the PR, good luck with getting it merged. Let me know here if you need some help - I get e-mail notifications for questions.
@adrian_dsl: I put together the patches required to get the SATA port reconfigured as PCIe: https://github.com/BenjKeiser/clearfog_gt8k_patches/tree/main .
1 Like