Wait, what? That’s trivially not true – the driver in the buildroot image is two modules (mlan.ko and pcie8897.ko) and has symbols that look like the sd8897 driver that can be found elsewhere (as linked earlier) and mwlwifi is one (mwlwifi.ko) whose symbols look nothing like either.
umiddelb, I found your tree in the other thread (thank you!!) and was able to get it built and booted. Both mwifiex and mwlwifi build and load (obviously not simultaneously), which is great!
However, the Marvell driver appears to let you set the card as an AP for both 2.4ghz and 5ghz simultaneously and for the life of me I can’t figure out how to make mwlwifi or mwifiex do that. mwlwifi’s docs seem to suggest that I should have two phys, but I can only get one to show up. I know the hardware’s capable of it since, well, like I said, I got it working with the Marvell driver on Globalscale’s kernel. Any advice?
Do you have a 4.12 DT with the SD card working and, if so, can you post it somewhere? Also, can you post the precise firmware blobs you’re using?
Also, were you able to get mwifiex working with multiple phys for 5GHz and 2.4? I briefly managed to get mwifiex working at one point, but as far as I can tell, the number of phys in mwifiex is fixed at 1 and you have to pick between 5 and 2.4 (whereas the marvell driver lets you do both). I suppose if you have 4.12 working I can try mwlwifi, though.
No, the wifi card shipped with my Espressobin was a Marvell 8W8897.
Hello Bryan and other Globalscale folks,
Any word on this? Failing that, any updates on the mainlining work?
The Espressobin device tree in mainline does not have the SDHCI controller for the SD card slot enabled, so unless you want to figure out what how it needs to be augmented to have that, you’re out of luck as far as the SD card goes. The SATA port or USB will probably work, though.
Wifi: the “mwifiex” driver in mainline _might_ work. The version in the Marvell tree panics on load most of the time for me, but the mainline version might have fixes. I have admittedly yet to try with different firmware versions. Note, however, that as far as I can tell, mwifiex only supports one AP interface at a time, instead of the two that the 4.4.8 binary Globalscale provides does – I believe that means you need to pick one of 2.4GHz or 5GHz if you want to use it in AP mode. Alternatively, there’s https://github.com/kaloz/mwlwifi, which I haven’t had luck with on 4.4.8 or 4.4.52, but might work with 4.12.
Good luck! Please report back.
While admittedly the files in Steam Link SDK’s version of the mlan driver claim to be Marvell confidential in the headers, https://android.googlesource.com/kernel/tegra/+/android-5.0.0_r0.10/drivers/net/wireless/sd8897/ is an example of a Marvell 8897 WLAN driver whose mlan source in fact claims to be GPL. So it’s definitely hard to believe that it’s going to be impossible to redistribute source for this very similar driver.
Hello Bryan and other Globalscale folks,
I don’t want to be a pain, but I really must insist on a timeline for source availability for the Marvell WLAN driver.
The driver has two parts: mlan.ko and pcie8897.ko. pcie8897.ko declares itself as GPL, so you’re _required_ to redistribute the source for that. mlan.ko claims to be proprietary…but a bit of Googling turns up _multiple_ copies of source code for a Marvell 8W8897 driver that looks strikingly similar in terms of symbol names to the mlan.ko+pcie8897.ko combination (e.g. https://github.com/ValveSoftware/steamlink-sdk/tree/master/kernel/arch/arm/mach-berlin/modules/wlan_sd8897), only missing the pcie bits. In short, unless there’s some really complicated stuff going on in the PCIE glue (which seems doubtful to me), it’s hard to believe given the availability of that that mlan.ko is closely-held trade secret intellectual property that Marvell will not divulge under any circumstances.
I need to build some additional functionality into the kernel running on my espressobin to be able to use it for what I paid for, and I’d like to be able to do so without giving up the ability to use the wifi card that I also paid for. Please help a customer out here.
This Arch tree doesn’t seem to work very well – at least one of the Marvell network drivers doesn’t build (resulting in it not detecting the switch and two network ports not working as a result). The mvebu PCIe driver in it doesn’t build either
Squashfs is indeed not compiled into the Globalscale kernel:
glasgall@latte:~$ zgrep SQUASH /proc/config.gz
# CONFIG_SQUASHFS is not set
You can build a kernel (following the instructions on the wiki) with support for it compiled in or as a module, but you’ll have to give up wifi support until Globalscale gives us source for the Marvell 8W8897 driver so we can build it for custom kernels.
The EspressoBin, like most ARM boards, uses the Das U-Boot bootloader. You’ll need to make the changes in u-boot.
Reboot the board, hit a key to interrupt the automatic boot, and use “printenv” to list the environment variables. You can use “setenv” to change variable values for this boot and “saveenv” to write the new values to persistent storage.
The Marvell kernel/device tree blob does not expose the on-chip NOR flash, unfortunately, so you cannot do this from Linux right now.
It’s only ever powered on for me at all – running ubuntu or buildroot – with the 12v adapter plugged in.
I don’t think another userland would make a difference. I’m using the kernel from the Globalscale buildroot image (which defaults to the performance governor), and the buildroot image doesn’t do anything to change that (so the Globalscale buildroot image would have the same behavior). The panic on trying to change governors is definitely a kernel issue, not a userland one.
I did this with Ubuntu rather than Debian, but the debootstrap process is the same. You’ll want to follow the steps in https://wiki.debian.org/EmDebian/CrossDebootstrap, and then do the same post-configuration as is done in the wiki instructions for creating an Ubuntu root filesystem.
You will need to either use Globalscale’s kernel and modules (extractable from their Buildroot rootfs) or build your own kernel (following the instructions on the wiki). Note that doing the latter will mean you won’t have working wifi drivers, if you bought an Espressobin with the Marvell wifi card.
The first thing you’ll want to do is probably to add “net.ifnames=0” to your kernel command line to disable network interface renaming.
The next thing you’ll need to do is make sure you bring up eth0 (no address is needed, it just needs to be up) before bringing up wan. You can do this by adding “pre-up ifconfig eth0 up” to your /etc/network/interfaces stanza for wan.
If this is just the rootfs that was on the SD card, I already extracted the kernel and modules from it and am using it in the Ubuntu 16.04 rootfs I built, but thank you.
Do you have any idea what the timeline for obtaining driver source is going to be like? I would very much like to be able to add some additional stuff to the kernel running on my espressobin.
Also, I don’t want to be a pain, but the pcie8897/mlan driver is at least in part GPL code, according to module license declarations…
(PS: The in-tree mwifiex driver, at least as of Marvell’s 4.4.52-17.06 tree, panics immediately on load. The various “mwlwifi” trees I’ve found elsewhere either don’t build against 4.4 or also panic on load. So I can’t use either of those and really do need the pcie887/mlan driver source, at least until such time as mainline support for the board happens. I’m very happy to see the work you’re doing with Free Electrons to make that happen!)
Technical specification tables can not be displayed on mobile. Please view on desktop