Hi,
I got my hands on Netgears Orbi Pro home meshing kit.
They look really good and hardware is nice, but software is one of the usual let's throw some old version of QSDK and slap a couple of binary tools with a huge array of scripts and it will be fine.
Not to mention that Web UI is really badly slapped together and it's not looking good even visually, especially not for 500 euros.
So as usual with any device, I get my hands on I want to get OpenWrt working and merged.
Specs are the following:
IPQ4019
512MB of DDR3
4096MB of EMMC storage
No NAND
2.4 and 5Ghz 2x2 radios from IPQ4019
QCA9984 4x4 dual-band PCI-e card(Presumably used only for meshing)
5 port gigabit switch
And TLC59208F I2C 8bit LED driver for the LED ring for which they wrote a driver.
So far I got initramfs loading and not crashing.
All radios are detected by ath10k
PCI-e and I2C are working
But the issue now is getting the sdhci-msm driver going.
Since no board uses EMMC so far in OpenWRT there is no sdhci node in dtsi.
I got that patched in and added a voltage regulator for the SD.
Also, there were gpio pins in sdio_cmd and sdio_clk groups which are not defined in the kernel driver.
I don't know if that will cause the issue.
It gets loaded during boot but there are 3 errors,one of them is supposed to be optional but gets thrown anyway.
My sources are here:https://github.com/robimarko/openwrt/tree/Netgear-Orbi-Pro
And latest bootlog is here:https://gist.github.com/robimarko/3959a7d8fece277b911c4ccd27b53b8c
Can anybody provide some assistance to get EMMC detected and readable?
Thanks
blogic used to roll a Orbi Image in his staging repository back when ipq40xx was under the ipq806x umbrella:
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/ipq4019
you could try and compile the old 4.9 code. But I don't know if he managed to get emmc supported or not.
Awesome,it looks promising.
He basically extracted the regulator and SDHCI driver from GPL.
I dont think that that is neccessary as everything should be upstream.
But his configuration of the regulator and SDHCI node is crucial
Is the regulator really upstream? I can't find the "qcom,regulator-ipq4019" binding in /Documentation/devicetree/... The best I could find was this:
https://patchwork.kernel.org/patch/8744371/
with the state: "Deferred, archived"
Yes,I saw that.
But if you look at the patch,it does not introduce a new driver.
Only binding docs and the node itself.
I think that I am gonna patch in regulator driver from GPL like blogic
Damn,I was googling for part 2 and was not able to find it.
I wish that patchworks finally get a simple series view and a search.
I have to add, I don't know if the posted driver (or the one from John) does work or not. I don't have any of these expensive IPQ40xx and the person that contacted me to work on his Orbi has disappeared.
Off course, I will test if it works.
Well,I think that it is safe to tell that that one in Qualcomms patch does not work
SD0 VccQ: failed to get the current voltage(-22)
[ 0.090617] regulator-ipq4019 1948000.regulator: Failed to register regulator: -22
[ 0.090654] regulator-ipq4019: probe of 1948000.regulator failed with error -22
And kernel crashes.
So,I will try blogics approach.
Blogics driver does not crash,but it does not show in the log either
I briefly looked at the diff between the regulator code. John's has this extra:
drvdata->range = 1800000;
line in his.
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=blob;f=target/linux/ipq806x/patches-4.9/313-ipq4019-regulator.patch;h=f13e93990d79063215e33085d796f99eb7123952;hb=6a64b4b056175c9e2cc5397240b38b188d674240#l237
which could explain some of the -22 (Einval) fallout from ipq40xx_regulator_get_voltage()... But anyway.
Did you try John's emmc driver as well? Because the driver upstream seems to be substantial different (as in missing some stuff) from the one he extracted.
Edit:
(Forgot about this): John's regulator driver uses the old "qcom,regulator-ipq40xx" binding. You either have to edit the driver or the dts.
I am just patching Johns driver for SDHCI
I edited the dts to qcom,regulator-ipq40xx binding
Ok,patched it in.
There are some changes,but still not detecting MMC.
sdhci_msm 7824900.sdhci: Failed to get slot index -19
Got it a couple of minutes ago and with alias used its building.
Thanks anyway.
Now it detects the EMMC but a few new errors.
I forgot to add pinctrl group to it.
After passing pinctrl group there are still some errors but MMC is detected as well as partitions on it.
Now to tackle calibration
Are you talking about these errors?
[ 1.108072] ipq4019-pinctrl 1000000.pinctrl: pin_config_group_set op failed for group 6
[ 1.114450] ipq40xx-mdio 90000.mdio: Error applying setting, reverse things back
If so, then I think I can explain what's going on. In your dts you have:
https://github.com/robimarko/openwrt/blob/Netgear-Orbi-Pro/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-orbi-pro.dts#L228
The problem here comes from the "bias-bus-hold" .
The IPQ40xx pinctrl does not support the keeper configuration. We discovered this back in the day
when we had to deal with the qpic nand (http://lists.infradead.org/pipermail/lede-dev/2017-May/007425.html). Thankfully, QCOM fixed the issue ( http://lists.infradead.org/pipermail/lede-dev/2017-May/007424.html )
GPIO_PULL bits configurations in TLMM_GPIO_CFG register
differs for IPQ40xx from rest of the other qcom SoC's.
This change add support to configure the msm_gpio_pull
bits for ipq40xx, It is required to fix the proper
configurations of gpio-pull bits for nand pins mux.
IPQ40xx SoC:
2'b10: Internal pull up enable.
2'b11: Unsupport
For other SoC's:
2'b10: Keeper
2'b11: Pull-Up
As a result, you have to replace the bias-bus-hold; property with bias-pull-up;
Edit:
I had this device definition in one of my mails. Maybe you can use some parts of it.
define Device/netgear_orbipro
$(call Device/DniImage)
DEVICE_DTS := qcom-ipq4019-orbi-pro
BLOCKSIZE := 4k
PAGESIZE := 256
DEVICE_TITLE := Netgear Orbi Pro
IMAGE_SIZE := 29753344
KERNEL_SIZE := 3932160
NETGEAR_BOARD_ID := RBR50
NETGEAR_HW_ID := 29765352+0+4000+512+2x2+2x2+4x4
IMAGES := sysupgrade.tar mmcblk0p12-kernel.bin mmcblk0p14-rootfs.bin factory.bin
IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to $$$${BLOCKSIZE} | sysupgrade-tar rootfs=$$$$@ | append-metadata
IMAGE/mmcblk0p14-rootfs.bin := append-rootfs | pad-rootfs | pad-to $$$${BLOCKSIZE}
IMAGE/mmcblk0p12-kernel.bin := append-kernel
IMAGE/factory.img := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | append-uImage-fakeroot-hdr | pad-to $$$$(KERNEL_SIZE) | append-ubi | netgear-dni
DEVICE_PACKAGES := ath10k-firmware-qca9984 e2fsprogs losetup
endef
TARGET_DEVICES += netgear_orbipro
Awesome,thanks for that.
Yeah,I am talking about that eror as well as Vreg errors in SDHCI.
But those Vreg errors dont looke like dealbreakers as MMC can be read normally.
Thanks for the image definition,already got most of it set.
Thankfully DniImage is not needed here
Only need to correctly set factory and sysupgrade images.
Will do that after I get board-2.bin for QCA9984 done and networking set.
I like to get everything working with initramfs and then move on to flashing after backing up
A lot of boards use eMMC perfectly fine with OpenWrt... SolidRun's products for example (ClearFog & ClearFog Pro), among others.
I meant QCA based boards since drivers for ClearFog mvebu are different.
)