<hurricos>
that said, it claims this is a "generic" shift control register ... so
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
snh_ has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<neggles>
hurricos: usually you'd use spi to drive a shift register but there should be a module for doing it via gpio
<blocktrron1>
hurricos: when your chip is not connected to a SPI bus of your SoC, you can just use the bitbanged spi-gpio driver and add the binding there
<neggles>
yeah i was about to say
<blocktrron1>
see the archer c58 / fritzbox 4020 as an example
victhor has quit [Remote host closed the connection]
<neggles>
fairchild,74hc595.yaml is not present in 5.10.87 hmm
<blocktrron1>
nick[m]1234: can you provide a full bootlog of your nanostation m5?
<blocktrron1>
just to be sure it is the correct chip
<blocktrron1>
the locking pattern is a bit odd, BP3 looks to be a TB bit on crack, i can not figure out the pattern locking s applied in case it is set
<Namidairo>
i wish to hand avm the award for ugliest hardware
<blocktrron1>
neggles: pre dt-schema
<blocktrron1>
Namidairo: :(
<neggles>
ah
<neggles>
ahhhh right yes the generic 74x164
minimal has quit []
dangole has quit [Remote host closed the connection]
philipp64 has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
srslypascal is now known as Guest9330
srslypascal has joined #openwrt-devel
Guest9330 has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
<hurricos>
blocktrron1: Thank you very much for those examples. I was totally unaware you could do such madness. This is very fortunate :^)
<hurricos>
I'll try it immediatley
slh has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64 has quit []
<neggles>
I wonder. can you set up GPIO SPI on top of a GPIO expander that is itself connected to GPIO SPI?
<neggles>
if so, how deep does the rabbit hole go
<hurricos>
it's like USB
<hurricos>
i.e.
<hurricos>
horrifying
<neggles>
I can see no reason why you wouldn't be able to go several levels deep with an SoC with fast enough GPIO pins
<neggles>
limiter would probably be minimum spi clock of the gpio spi driver or final device...
onemarcfifty has quit [Remote host closed the connection]
onemarcfifty has joined #openwrt-devel
marc__ has joined #openwrt-devel
fda has joined #openwrt-devel
onemarcfifty has quit [Ping timeout: 480 seconds]
marc__ has quit [Remote host closed the connection]
marc__ has joined #openwrt-devel
Borromini has joined #openwrt-devel
marc__ has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: you got a GPL dump from extreme for these APs, iirc? feel like sharing? they haven't even activated my support portal account yet >:(
rua1 has joined #openwrt-devel
nlowe has joined #openwrt-devel
hitech95 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
nlowe has quit []
nlowe has joined #openwrt-devel
<nick[m]1234>
blocktrron1: I think it was not the lock, it was just missing flash... Sorry. Wrote just a new email via mailinglist
<blocktrron1>
nick[m]1234: i doubt that
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<blocktrron1>
you have over 2MB of free overlay space
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
victhor has joined #openwrt-devel
<nick[m]1234>
blocktrron1: you could be right. I tftpflashed the factory image. Probably because of that I did not see the jaffs2 errors
<JuniorJPDJ>
hey, what is .uc file? I'd like to play a bit with fw3 to add one feature
<blocktrron1>
Can you build with this patch? just threw this together, gives us an idea if kernel is locking by itself and if not, some assertions down the line in the unlock routine fail
nlowe has joined #openwrt-devel
<blocktrron1>
If you look at the datasheet of you flash chip, the locking behavior is in line with the codes expectation for all states where BP3 is unset
<blocktrron1>
Anyways, this patch always clears BP{0-3}
dangole has joined #openwrt-devel
castiel652 has joined #openwrt-devel
<nick[m]1234>
blocktrron1: Thanks I will test it! :)
pmelange has joined #openwrt-devel
<nick[m]1234>
blocktrron1: it did not help. still have those jaffs2 errors
onemarcfifty has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rua1 has quit [Quit: Leaving.]
nlowe has joined #openwrt-devel
rua has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JuniorJPDJ>
how can I test local firewall3 sources? i mean how to prepare env to build and run it
nlowe has joined #openwrt-devel
snh_ has joined #openwrt-devel
castiel652 has quit [Ping timeout: 480 seconds]
snh has quit [Remote host closed the connection]
onemarcfifty has quit [Read error: Connection reset by peer]
snh_ has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
castiel652 has joined #openwrt-devel
nlowe has joined #openwrt-devel
onemarcfifty has joined #openwrt-devel
danitool has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
KGB-1 has joined #openwrt-devel
Borromini has quit [Quit: leaving]
dangole has quit [Ping timeout: 480 seconds]
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hauke>
JuniorJPDJ: You can ue SRC_TREE_OVERRIDE and point to a local checkout of fw3
<blocktrron1>
you'll have to flash the resulting image using TFTP from the bootloader, as i suspect the current firmware will not be able to write to the flash
<hurricos>
if LEDs are driven by a shift register ...
<hurricos>
can I possibly expect to be able to light up one LED without lighting the others?
<hurricos>
except of course the first one.
<hurricos>
I'm worrying that the WS-AP3825i having its LEDs driven by a shift register means the model is completely wrong and I'm doing the device tree the wrong way
<hurricos>
you can't call the outputs of a shift register a GPIO
<hurricos>
so why can you register LEDs against them?
<hurricos>
mosi vs miso ... I suspect I am pointing at mosi, because the bus driver is my GPIO?
<hurricos>
bus master*
<hurricos>
I guess SPI is bi-directional
<hurricos>
and that's why this example has both?
<svanheule>
mosi is Master In - Slave Out; miso is the opposite
<hurricos>
err
<hurricos>
m i s o is mosi?
<svanheule>
right, sorry :P
<hurricos>
OK
<svanheule>
those are the words, I'll leave assembling them into an acronym as an exercise to the reader :^)
<hurricos>
So by giving spi.mosi-gpios = <&gpio0 $input_pin 0>, knowing 0 is low, I'm doing the right thing, I think
<hurricos>
for spi.compatible="spi-gpio", I should say
<hurricos>
though the device has no other spi
<svanheule>
if 0 means "active high" (would make sense, to have that as default)
<hurricos>
in reflection that the state of the $input_pin GPIO is the state that gets carried to the next shift register bit at every cycle of spi.sck-gpio <&gpio0 $clock_pin 0>
<hurricos>
alright, let's just see what happens when I compile and boot
<hurricos>
dmesg not giving me anything when it comes to debugging isn't helping me much :( I might have to start inserting printk to the spi-gpio.c device driver lmao
goliath has joined #openwrt-devel
<svanheule>
do you see the spi-master in sysfs?
<hurricos>
oh
<hurricos>
let me check in the bad currently-booted version
<hurricos>
err, ./class/spi_master/spi0 ?
<hurricos>
fwiw I also have spi-nor on the board
<hurricos>
so not sure if that's from that
<hurricos>
I can boot a pre-LED-attempt version to find out
<hurricos>
oh no
<hurricos>
this isn't that
<hurricos>
this is the spi device at address 0x7000
<hurricos>
so I should expect to see an spi_master e.g. "led_spi" (maybe)
<svanheule>
not sure what it will be called
<hurricos>
I do have /sys/firmware/devicetree/base/led_spi
<svanheule>
do you have the the driver for spi-gpio enabled?
<hurricos>
oh
<hurricos>
you know what
<hurricos>
god damn it
<hurricos>
I knew it
<hurricos>
it wouldn't be a default / builtin
<hurricos>
I was checking the ath79 build tree
<hurricos>
fwiw
<hurricos>
for other devices that bit-bang
<hurricos>
for other devices with shift registers*
<hurricos>
the one thing I didn't realize was the possibility that either 1) they didn't use bit banging or 2) they have spi-gpio on by default
<hurricos>
s/on/enabled/
<svanheule>
I would think it's pretty common, but wouldn't hurt to check to make sure you have all the required pieces :)
<hurricos>
yeah, I can also check System.map I think
<nick[m]1234>
should I flash from openwrt21.02 to this image?
<nick[m]1234>
via sysupgrade
<hurricos>
> in lsmod too < no, but they should be under /sys/module/. And the modules I'm looking for are not, despite CONFIG_SPI_GPIO being built
<hurricos>
So, either: 1) the module has no options and not having options prevents presence in /sys/module/, or 2) I've still fucked up and not actually added the spi_gpio module
<hurricos>
hahaha it was the latter =_=
<hurricos>
nope, it's there
af has joined #openwrt-devel
af has quit []
<blocktrron1>
nick[m]1234: your tree is omitting the patch which adds the ..._HAS_LOCK flag on the CPI chip in macronix.c
<blocktrron1>
So the lock functions are never called
<blocktrron1>
at that one on top
zenox has joined #openwrt-devel
Borromini has quit [Quit: leaving]
hitech95 has quit [Remote host closed the connection]
<nick[m]1234>
I don't know, I don't get any debug output
<nick[m]1234>
I even changed to dev_err
<nick[m]1234>
but nothin
<blocktrron1>
nick[m]1234: 4bitbp should not matter at this stage
<blocktrron1>
Try to determine, where the code does not follow the locking path
<blocktrron1>
e.g. check if spi_nor_unlock_all, spi_nor_unlock and spi_nor_sr_unlock get called at all
<blocktrron1>
Somewhere it seems it does not finish this call tree
<blocktrron1>
warn laglevel is the minimum compiled & printed by default afair
<nick[m]1234>
I will switch to printk ;)
<dangole>
blocktron1: i got XMDIO working on the unifi 6 lr but I only got 1000M PoE switch. so if you feel like playing with this AQR112C on 2500Base-T link (which will probably need more work)...
<dangole>
* blocktrron1
<blocktrron1>
dangole: do you have a tree somewhere?
<blocktrron1>
And are you in posession of the required firmware for the PHY?
<dangole>
blocktrron1: just pushed to master
<blocktrron1>
I can have a look
<blocktrron1>
AFAIR there was an SPI chip next to the PHY which might contain the firmware
<blocktrron1>
I don't have the device at my place ATM (and do not have a 2.5 NBase-T card)
<dangole>
blocktrron1: aq-fw-download works with AQR-G4_v5.4.B-AQR_CIG_WIFI_ID44715_VER1673.cld, i use kmod-mdio-netlink and mdio-tools to trigger the final blessing after firmware upload
eduardo010174 has joined #openwrt-devel
eduardo010174 has quit []
<dangole>
blocktrron1: ah interesting. i used a generic binary the winds had whispered.
valku has joined #openwrt-devel
<dangole>
blocktrron1: i got an 10GE/5GE/2.5GE/1GE/100M/10M intel nic, but no capable PoE injector, only 1000M PoE switch...
<blocktrron1>
PoE injector should not matter all to much someone told me
<blocktrron1>
I have no idea about that works, so i just repeat what i was told
<blocktrron1>
Just getting a generic microsemi one from ebay might be enough
<blocktrron1>
i cant give you an ETA on when I'll have access to the U6-LR again, as its 120 km northwards from me currently.
<blocktrron1>
But I''ll come back for the firmware
<nick[m]1234>
blocktrron1: spi_nor_unlock and spi_nor_sr_unlock are definitelycalled
<nick[m]1234>
spi_nor_try_unlock_all is not called
<blocktrron1>
nick[m]1234 you mean "spi_nor_unlock_all" ?
<nick[m]1234>
no spi_nor_try_unlock_all, the other function does not exist?
<blocktrron1>
there is no try_unlock_all in 5.10
<nick[m]1234>
I don't know if something got backported? Where can I find the 5.10 branch from the linux kernel?
<blocktrron1>
give me a sec
<nick[m]1234>
openwrt is at 5.10.87
<blocktrron1>
I've notices i'm on the v5.10 tag, not stable branch