Controlling LEDs through a 74x164 shift register

Yeah,HC595 in Linux is not using full SPI but rather simplified version.
Kernel is seeing the shift register as you can see it being registered as device and kernel module for it is loaded.

GPIO pins are correct,they are defined in patch to add 74x164 driver in the GPL sources.

It says fairchild,74hc595 because driver supports 2 different models and this is classic HC595.
You can see that in kernel documentation about 74x164 I already linked before.

Issue is that kernel is not exposing registered LEDs

Right..

In the stock firmware, the 'base' for the shift register is 248, and all the LEDs are 248 to 254.

Is that 'base' a guess by Netgear, or is there a reason for it, like maybe it's an address or something?

Tim

I asked Tom about this, and he suggests the following:

Looks like you're missing the "spi-gpio" module. The setup in my DTS is
a bit convoluted, and it needs two separate drivers to operate: the
first, spi-gpio, allows the kernel to bitbang GPIO pins in order to
drive an SPI device. In this case, it bitbangs GPIO 4 and 5, which
are
connected to the shift register. The second, gpio_74x164, exposes
that
shift register's outputs as GPIOs of their own. If either module is
missing, the shift register's GPIOs won't appear and so the LEDs
won't
be registered.

The architecture is like this:

GPIO (IPQ4019) 4 & 5 ---> "dummy" SPI bus ---> GPIO (74x164) 0-6

I call the SPI bus a "dummy" because the protocol isn't really SPI.
The shift register just takes a clock and a data, which happens to
look
enough like SPI that the gpio_74x164 module can pretend that it's
driving an SPI bus and reuse the generic SPI kernel code. But there
are
no chip selects, no MISO line, and it doesn't follow any standard SPI
protocol like SMBIOS.

Nevertheless, since the gpio_74x164 expects an "SPI" bus to exist, we
need the spi-gpio module to provide that SPI bus--in this case, by
just
using GPIO 4 and 5 of the IPQ.

I'm currently compiling the spi_gpio module into the initramfs..

Tim

It worked! Compiling the spi_gpio module and the /sys/class/leds is populated!

I can toggle all the LEDs using the /sys/class/leds/ interface too!

So, there's still a couple of errors on the pre-cal data and the firmware-6.bin is missing (I think I can just copy the firmware-5.bin for that, can I?).

Tim

Can you push those changes as a pull request?
Also,please give me bootlog.
firmware-6 errors are normal as 4019 does not use firmware-6 at all.

Here's the bootlog:

All I did was enable the 'CONFIG_PACKAGE_kmod-spi-gpio=y' option.

I'll make the changes permanent in the wac510 profile, then see about a pull request - this is still new to me!

This image is looking for board.bin too, not board-2.bin. Is that significant?

Tim

Ok.
I can add that package to the profile.

QCA4019 does not need board.bin at all,it only uses board-2.bin
Most likely I made a syntax error somewhere.
Gotta look into that since bmi and everything match those in board-2.bin.

Did you check if the LEDs match those on the device?

Thanks for adding it - probably better if you do it this time round :slight_smile:

I did check all the LEDs, and they are all named correctly.

This device has an eth0 and eth1 - I can toggle the eth1 by toggling gpio62. I haven't tested eth0 yet. When I turn on gpio62, the LED blinks as expected as network traffic passes. Do we need to do anything else with them as they appear to be working?

Tim

Ok, great.
We gotta set triggers for LEDs, otherwise, you gotta do it manually.
Does power LED turn on automatically?

Also, does current ethernet configuration match physical ports?

We really need to fix radios.

The issue with LEDs and DTS was, of course, a stupid one, missing kernel mod.
When I was working on Jalapeno I spend god knows how many hours finding the issue in DTS since NAND was not getting detected and in the end, the issue was that I did not enable the driver for it to be built.
99% of the time its stupid mistakes like those.

Any update?

Yeah, I've been setting up the LEDs in the /etc/config/system file, and am about to start on the wifi configs and firmware.

I'm assuming that editing the /etc/config files is the right way to set up the LEDs?

The reset button works already - 'REBOOT' is printed on the console when I press it, then the device reboots.

I'm hoping I'll get to grips with github and be able to generate pull requests to your branch to update it.

Tim

LEDs need to be set in target base files.
That way they will trigger for all people.
I can make some general triggers for them.

Can you check if ethernet ports in OpenWRT match ones on the device,aka if WAN port is defined as WAN and LAN too

OpenWrt ports are eth0/1. The device has WAN/LAN labels on the back, but they're not defined in OpenWrt.

I think eth0/1 should be swapped anyway - the WAN/eth1 port is the only PoE port which will be used for most deployments, so surely that should be eth0 (ie, the default port people will be using)?

Tim

Ok,so they are swapped.
Will fix that.

You cant change eth0 to eth1 as they are physical ports

Where do I set up the LED triggers? I was putting them in package/base-files/files/etc/config/system, but that seems to get included in all profiles when I try compiling them.

I thought I read about someone changing eth0/1 by modifying the DTS file? Did I get that wrong then?

The eth1 port comes up on bootup, but the LED doesn't light (and flash with traffic) until I do this:
root@OpenWrt:/# echo 62 > /sys/class/gpio/export
root@OpenWrt:/# echo out > /sys/class/gpio/gpio62/direction
root@OpenWrt:/# echo 1 > /sys/class/gpio/gpio62/value

When I do that, this is printed on the console:
[ 1182.964329] ess_edma c080000.edma: eth1: GMAC Link is down
[ 1184.005245] ess_edma c080000.edma: eth1: GMAC Link is up with phy_speed=1000

If I pull gpio62 to 0, eth1 LED turns off and the port is disabled. It only turns on again by pulling gpio62 high..

So, it seems that setting gpio62 high somehow resets eth1 and makes the LED work. How is that happening, and can we get the LED to come on automatically at bootup?

Sorry for being slow - I have small children who distract me at the weekends.

Tim

LEDs are defined by target in base files.

I will make some triggers today.
That should make eth LEDs work automatically.

Does Power LED work automaticaly by default?

Also,you can swap eth0 and eth1,they are physical ports and they detected that way by kernel.
Can you check with ifconfig if MAC adresses match those on sticker.

Its weird that Netgear SDK does not mention WAN or LAN LEDs for WAC510 at all

I have added triggers for all LEDs.
Also,I have defined GPIO62 and 63 as WAN and LAN LEDs and set them to active high and their default state to keep.
So if U-boot like I think actually sets them kernel will just keep that state,manually setting them to on would cause a glitch and phy reset.
So,please test latest version of the branch and verify that eth0 aka LAN led also works.

Having trouble in making a 'push request' through github...

Line 278 in target/linux/ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-wac510.dts has a typo - duplicate wan statement. I changed it to 'lan' and it compiled ok.

GPIO62/63 mods haven't worked. I tried setting them as 'default-state: on' and it also had no effect.

I don't think those GPIO's are simple LEDs - they toggle the state of the eth port, not just the LED.

I've gone through all the other gpios and nothing is toggling the eth LEDs. I've got all the Netgear firmware decompiled on my work PC, so I can check tomorrow on how they initialise the eth LEDs.

Tim

Its Pull request.
You simply make changes in your forked branch,commit them and then you can click compare and make pull request or new pull request.

Ok,but even if they are not LEDs after setting them to default on that pull the GPIO high.
And you said that that pulling GPIO62 high did get LEDs to work.
Also,it cant be GPIO63 as that is reset button
Maybe they are active low,can you try echoing 0 as their value?

I digged through the GPL and only WAC505 has GPIOs specific to eth and port speed.

Also,whats the FCCID so I can see which switch it uses

Ahh, OK.. I've just cloned your branch to my local PC. I'll try setting up my own forked branch..

I can't export GPIO62 to try pulling it low/high anymore:
root@OpenWrt:/# echo 62 > /sys/class/gpio/export
ash: write error: Resource busy
root@OpenWrt:/#

I thought it was because you had GPIO62 defined in the DTS, so I tried removing the definition from there and re-compiling my initramfs, but it still gives me the same error (resource busy). Is GPIO62 defined anywhere else to make it 'busy'?

MAC address on the device matches eth0.

FCCID: PY316200355
IC: 4054A-16200355

If I enable wifi in /etc/config/wireless, both 2.4G and 5G work and I can connect to them. Range isn't great, but I'm still getting these errors on bootup:
[ 8.485198] ath10k_ahb a000000.wifi: Direct firmware load for ath10k/pre-cal-ahb-a000000.wifi.bin failed with error -2
[ 8.485292] ath10k_ahb a000000.wifi: Falling back to user helper
[ 9.891273] ath10k_ahb a000000.wifi: Direct firmware load for ath10k/QCA4019/hw1.0/firmware-6.bin failed with error -2
[ 9.891326] ath10k_ahb a000000.wifi: Falling back to user helper
[ 9.962205] firmware ath10k!QCA4019!hw1.0!firmware-6.bin: firmware_loading_store: map pages failed
[ 9.964273] ath10k_ahb a000000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000
[ 9.970100] ath10k_ahb a000000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 9.988186] ath10k_ahb a000000.wifi: firmware ver 10.4-3.4-00104 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 6c332c67
[ 10.029792] ath10k_ahb a000000.wifi: board_file api 2 bmi_id 0:16 crc32 de67223f
[ 11.372386] ath10k_ahb a000000.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 11.564969] ath10k_ahb a800000.wifi: Direct firmware load for ath10k/pre-cal-ahb-a800000.wifi.bin failed with error -2
[ 11.565047] ath10k_ahb a800000.wifi: Falling back to user helper
[ 13.022431] ath10k_ahb a800000.wifi: Direct firmware load for ath10k/QCA4019/hw1.0/firmware-6.bin failed with error -2
[ 13.022484] ath10k_ahb a800000.wifi: Falling back to user helper
[ 13.083639] firmware ath10k!QCA4019!hw1.0!firmware-6.bin: firmware_loading_store: map pages failed
[ 13.083942] ath10k_ahb a800000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000
[ 13.091535] ath10k_ahb a800000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 13.109477] ath10k_ahb a800000.wifi: firmware ver 10.4-3.4-00104 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 6c332c67
[ 13.150832] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17 crc32 de67223f
[ 14.493527] ath10k_ahb a800000.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1

Also, the power LED doesn't come on at bootup. I can make it come on by using these commands:
uci set system.led_power=led
uci set system.led_power.name='POWER'
uci set system.led_power.sysfs='wac510:green:power'
uci set system.led_power.default='on'
uci commit
/etc/init.d/led restart

But when I tried to add something similar to target/linux/ipq806x/base-files/etc/board.d/01_leds it did nothing. Is that not the correct place to add them? I notice that your definitions of the other LEDs have gone from there now, too?

So close! Thank you for your help thus far, Robert..

Tim