<G10h4ck>
nbd are you around? I managed to get WDS AP - AP communication working with good performance, with little modifications to hostapd, thanks for suggestions!
<nbd>
hi
<nbd>
cool
<G10h4ck>
I am redacting a bit of documentation about how it works, so if someone else would like to fiddle with it a little more while I have to work into other things
<G10h4ck>
I am going to wireless community weekend in Berling, will you be around? Do you know someone who will get there that might be interested in this stuff?
<nbd>
unfortunately i won't be able to make it this time
<nbd>
i'm looking forward to taking a look at what you built
cbeznea has joined #openwrt-devel
<xback>
Lechu: Looking good
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
rua has quit [Quit: Leaving.]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
minimal has joined #openwrt-devel
daiyeqi has joined #openwrt-devel
daiyeqi has quit []
<rmilecki>
hauke: i can't compile ramips anymore
<rmilecki>
cc1: fatal error: ../dts/mt7621_snr_snr-cpe-me1.dts: No such file or directory
<rmilecki>
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ecdb24814f540cb67cfa0ca64f32d76889853d15 ("ramips: add support for SNR-CPE-ME1")
<rmilecki>
"mt7621_snr_snr-cpe-me1.dts" ← compiler is looking for this
<rmilecki>
"mt7621_snr-cpe-me1.dts" ← this we have actually
tidalf has joined #openwrt-devel
<hauke[m]>
There is a pull request with the fix at GitHub already
tidalf__ has quit [Ping timeout: 480 seconds]
djfe has joined #openwrt-devel
djfe_ has quit [Ping timeout: 480 seconds]
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
hadis has joined #openwrt-devel
<hadis>
I have been porting openwrt onto a 3D printer board but there are two things that I can't work out.
<PaulFertser>
hadis: hi! Interesting, why are you doing that? And what's your problems with porting specifically?
<hadis>
1. the device has a usb mux chip (I thikn that's what it's called?) That switches which device is connected to the single USB bus. I don't even know where to start tackling this since there's nothing about it that I can find int he kernel logs or the device tree.
tidalf_ has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
<PaulFertser>
hadis: do you have schematics? Can you read the marking on the chip? Do you have some reasonably high-res photos of the board probably?
rua has joined #openwrt-devel
<robimarko>
It could just be a standard USB hub that you dont need any special drivers
tidalf has joined #openwrt-devel
<PaulFertser>
Then it would be visible in the kernel logs, as a standard usb hub is a USB device too.
<hadis>
Ah, stock meaning chinese fork of openwrt from 2015
<PaulFertser>
"machine is MediaTek LinkIt Smart 7688" is it really that?
<hadis>
Ah, no that's not it!
<hadis>
They just based it off that hardware
<hadis>
In the photos you see a small daughterboard on a big motherboard. That daughterboard is the linux board
<PaulFertser>
And that daughterboard isn't a linkit smart, just somewhat compatible, right? OK.
<hadis>
Also yes lsusb shows a usb hub but also only every one usb device (webcam or usb port) at a time
<PaulFertser>
Still good to know it's similar.
<PaulFertser>
hadis: please explain more about the topology. Is this SoC supposed to act as a USB host or as a USB device?
<hadis>
I was able to copy the Linkit device tree and make it work with the printer actually! So they are very compatible
<PaulFertser>
hadis: do you mean it's a USB host and either webcam or externel usb port for connecting external device can be chosen in the vendor's firmware?
<PaulFertser>
hadis: have you checked /sys/kernel/debug/gpio , have you saved it somewhere for the reference?
<hadis>
The SoC is supposed to control custom firmware on the mainboard. It's also supposed to either stream the webcam over the network or read usb sticks connected to the single usb port.
tidalf_ has quit [Ping timeout: 480 seconds]
<hadis>
The device connected can be switched at runtime and the stock operating system even manages to switch automatically to the usb port when something is plugged in
<hadis>
I will check the gpio directory
<PaulFertser>
hadis: it's a file.
<hadis>
I didn't know anything about this a couple weeks ago when i started porting so I apologize for silly questions and oversights
<PaulFertser>
hadis: so are you saying basically vendor firmware can switch between the connector marked "USB-HOST" and the one next to it called "CAMERA"?
<hadis>
I didn't even know what uart, logic analyzers or u-boot were two weeks ago... It's been a ride
<PaulFertser>
hadis: mainboard firmware running on GD32F103 MCU?
<hadis>
I would also like to mention that everything about this device is hacked together and most things don't work as they are supposed to inernally
<PaulFertser>
hadis: haha, you're very lucky to find this target, it's not too hard and it has all the essentials, and you have good motivation, so really way to go.
tidalf_ has joined #openwrt-devel
<hadis>
PaulFertser: I don't think the large mainboard has anything to do with USB. Only the linux board.
<hadis>
The mainboard runs on an stm32 I think
<PaulFertser>
hadis: I clearly see GigaDevices MCU there on the picture.
<PaulFertser>
hadis: do you think it might be that U15 IC between the connectors that is muxing the USB? Can you read all of its markings?
<PaulFertser>
hadis: GD32F103 is almost pin-to-pin and firmware compatible with STM32F103.
<hadis>
ah, that makes sense. I actually didn't inspect the mainboard much. On the software side of things I handle it like it's an stm32
<PaulFertser>
hadis: do you reflash it via SWD?
<hadis>
https://pastebin.com/GQrnMREF The gpio file seems very useful! I also found in the kernel logs that GPIO-4 and 5 were CS pins
<hadis>
I did not reflash the mainboard firmware yet
<hadis>
I did not reflash anything as I'm still booting openwrt over the network
tidalf has quit [Ping timeout: 480 seconds]
<hadis>
I will look for the U15 IC
<PaulFertser>
hadis: probably gpio 14 controls the mux?
<PaulFertser>
hadis: make the vendor firmware switch the mux and then check that file again.
<hadis>
out lo vs out hi?
<hadis>
That makes a lot of sense!!
tidalf has joined #openwrt-devel
<hadis>
You got it!!!!!
<hadis>
That's the one
<PaulFertser>
Yay
<hadis>
I will note that and try it next I rebuild! :D
<hadis>
Thank you so much!
<hadis>
The second problem might be a lot harder to figure out so let me explain..
<PaulFertser>
hadis: and if you say it's capable to auto-detect plugging in, probably some other gpio changes too, gpio-41 probably? It's set as IN.
<PaulFertser>
hadis: in fact you can try any gpio without rebuilding, just use the sysfs export interface or "gpioset" command.
<hadis>
I will experiment with that on the openwrt system and if I don't figure it out I'll ask again
<PaulFertser>
hadis: we are all eager to hear about the second problem now :)
tidalf_ has quit [Ping timeout: 480 seconds]
<hadis>
Writing 0/1 to gpio 14 totally worked! Amazing!
<hadis>
In essence the second problem is that the MT7688 has 2 spi cs pins but thre spi devices connected to it.
<hadis>
I tried using cs-gpio in the device tree to use gpio 4 and 5 as chipselect pins but that didn't work at all.
<hadis>
This is the pinmux driver that I found in the kernel logs.
<hadis>
"The rt2880 pinmux can only set the muxing of pin groups. Muxing indiviual pins is not supported. There is no pinconf support."
<PaulFertser>
hadis: to use arbitrary GPIOs as chip selects you just need all the corresponding pins to be configured as GPIOs, not related to SPI etc.
<hadis>
And curiously, only two of the three devices are listed in the device tree that I dumped
<PaulFertser>
hadis: what is the third device and how do you tell it's working with the vendor firmware?
<hadis>
The first device is a spi nor flash chip and works. The second is an ili9341 screen and the third is an ads7843 touchscreen
<hadis>
the screen and touchscreen both work of course
<hadis>
you can see in the gpio pastebin from before which GPIO pins are used as CS
<hadis>
I listed them in that order because that's the order they came in in the DTS that I dumped
goliath has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
<PaulFertser>
hadis: I suggest you select the pingroup that makes all the pins that are used for CS purposes to be plain GPIOs.
<PaulFertser>
hadis: then you can try manipulating them from userspace manually and use a voltmeter to see if they have desired effect on the board.
<PaulFertser>
It likely has testpoints to easily access all CSs.
<hadis>
Now that I look at it.. In the GPIO file (https://pastebin.com/GQrnMREF) it lists gpio 0 as as fb_ili9341, gpio-5 as ili9341 SPI GPIO CS and 42 as fb_ili9341. Is it possible that the spi interface with ili9341 is entirely software emulated?
<hadis>
I don't entirely understand what you mean with that. You want me to figure out which group contains GPIO 4 and 5 right? What do I do from there?
<PaulFertser>
hadis: usually you have multiple devices on a single SPI bus and choose between them with CS lines.
<PaulFertser>
hadis: the flash memory is probably on its own SPI bus though.
<hadis>
yes
<hadis>
I understand that about SPI
<PaulFertser>
hadis: software emulated SPI is also kinda possible, called SPI bitbanging via GPIO, but either a kernel driver for that should be loaded or it can be a very slow userspace emulation. In either case it would be visible in debug/gpio file.
<hadis>
I was wondering about that. So since the spi-bitbang driver is not shown in the kernel logs nor in the debug/gpio file that driver is not used
Danct12 has quit [Quit: WeeChat 3.8]
<hadis>
Would it be possible with userspace emulation to configure a frame buffer device in /dev/fb0? If not then that's not what they did either
<hadis>
Also yes, the flash is on it's own SPI bus
<PaulFertser>
hadis: if it was userspace emulation, you'd see in gpio file.
<PaulFertser>
Not only CS but all SPI pins.
<hadis>
That was what my question earlier was about. Starting with "Now that I look at it [...]"
<hadis>
It does show three pins for the ili9431 screen.
<PaulFertser>
hadis: since only CS are listed then it means you're not supposed to use SPI hardware CS and instead use GPIOs for CS.
<hadis>
But there are three pins listed for ili9431!
<hadis>
gpio-0 (fb_ili9341 ) out hi
<hadis>
gpio-5 (ili9341 SPI GPIO CS ) out hi
<hadis>
gpio-42 (fb_ili9341 ) out hi
<hadis>
Which looks like CS, MISO and MOSI to me
<PaulFertser>
hadis: inspect /sys/devices/10000000.palmbus/10000b00.spi/spi_master/ , if all 3 are there, then it means all three are using hardware SPI controller. dmesg suggests that.
<hadis>
Then they are because I know that the devices are listed there
rua has quit [Quit: Leaving.]
fakuivan has quit [Remote host closed the connection]
<hadis>
As I've said before the whole device is jank! Only pinctrl0 is used, all the definitions outside of it but still within pinctrl in the device tree are unused
<PaulFertser>
hadis: since you dumped the whole device tree, probably it makes sense you see all the possible definitions, they're in the SoC dtsi file normally.
<hadis>
That helps! Now I think I know the syntax for defining the groups and functions properly
<hadis>
The only thing left is to figure out the cs-gpio definitions, right?
<hadis>
for cs-gpio I need to configure GPIO_ACTIVE_LOW or GPIO_ACTIVE_HIGH for each cs-gpio pin. Those values are client device specific, correct?
<hadis>
For example in this datasheet it lists "Chip select input pin ("Low" enable) under "CSX", I'm interpreting that as GPIO_ACTIVE_LOW
tlj has joined #openwrt-devel
tlj_ has quit [Ping timeout: 480 seconds]
<PaulFertser>
hadis: yep, CS almost always active low. Unless some inverters are installed along the way.
<hadis>
Yes that's what I found in the datasheets
<hadis>
I think I also figured out cs-gpio!
<hadis>
I will compile and give it a try!!
philipp64 has joined #openwrt-devel
rua has joined #openwrt-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #openwrt-devel
<hadis>
PaulFertser: I can't get it to compile successfully. This is the error: "Error: ../dts/mt7628an_flashforge_adventurer-3.dts:136.2-3 syntax error"
<hadis>
Oh. I forgot the semicolon on the previous line...
<hadis>
Nevermind!
<oliv3r[m]>
So i ignorantly built my target with mips_34kc as CPU type, and was getting 'illegal instruction' errors. So the old '24kc and 34kc is the same output from gcc' argument doesn't seem to hold any longer?
<schmars[m]>
oliv3r: there was a bug related to that recently, might be what you're seeing
<oliv3r[m]>
ah, ok, fair nuff
<schmars[m]>
Grep the git logs for the last couple of months
<oliv3r[m]>
i was curious what the difference in instructions would have been :)
<schmars[m]>
You might be right too
tidalf_ has joined #openwrt-devel
hadis has quit [Remote host closed the connection]
cbeznea1 has quit [Ping timeout: 480 seconds]
tidalf has quit [Ping timeout: 480 seconds]
hadis has joined #openwrt-devel
hadis has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
tidalf_ has quit [Ping timeout: 480 seconds]
fakuivan has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
tidalf_ has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
<f00b4r0>
we don't have the equivalent of "suggests" in opkg dependencies, right?
tidalf_ has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
tidalf has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
fakuivan has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
cmonroe has joined #openwrt-devel
goliath has joined #openwrt-devel
tidalf has joined #openwrt-devel
minimal has quit [Quit: Leaving]
tidalf_ has quit [Ping timeout: 480 seconds]
tidalf_ has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<f00b4r0>
so ipcalc.sh cannot, as is, provide a the number of ip addresses for a given <network/netmask> <start>, which would be damn convenient
swalker has quit [Ping timeout: 480 seconds]
<EqUaTe>
f00b4r0: dunno if it's available on openwrt, but sipcalc does very well for telling you the number of ip's in a network.. though what are you expecting to pass as '<start>' ?
<f00b4r0>
the beginning of a dhcp lease range
swalker has joined #openwrt-devel
<f00b4r0>
basically i have network/netmask and start, where netmask and start can vary, and I want the maximum value I can use in the "limit" dhcp lease conf
<EqUaTe>
don't know that I've come across any third-party tools that do that.. but at least some dhcp servers will tell you how many ip's in the pool when they start
<f00b4r0>
it looks like ipcalc.sh can be massaged to get there
<schmars[m]>
2 ^ (32 - $cidr) - 2 :-)
maciekb has quit [Read error: Connection reset by peer]
maciekb has joined #openwrt-devel
<f00b4r0>
i'm surprised this hasn't come up before :)
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
tidalf has joined #openwrt-devel
tidalf_ has quit [Ping timeout: 480 seconds]
Borromini has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
MaxSoniX has quit []
robimarko has quit [Quit: Leaving]
philipp64 has quit [Quit: philipp64]
AtomiclyCursed2 has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
hadis has joined #openwrt-devel
<hadis>
how do I build an openwrt image that already is configured as a client with dhcp?
<hadis>
I can't find the right options in make menuconfig
G10h4ck has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
karlp has quit [Quit: WeeChat 3.5]
karlp has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<PaulFertser>
hadis: oh, you're back, cool.
<PaulFertser>
hadis: OpenWrt has dhcp client by default on "wan" interface.
<PaulFertser>
hadis: so you got it all working?
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<jakllsch>
PaulFertser: and also a firewall
<PaulFertser>
jakllsch: default firewall allows dhcp client to work on wan, no problems.
<jakllsch>
well, yes, but can you access the machine that way?
<PaulFertser>
jakllsch: from the lan interface :)
<PaulFertser>
Or serial
philipp64 has quit [Ping timeout: 480 seconds]
<hadis>
PaulFertser: I had a bit of an emergency sorry for just leaving!
<hadis>
PaulFertser: I know that it's got dhcp and is a bridge by default but that does't make any sense for a 3D printer. I think the solution is the Image Builder, unless there's an easier way to configure a build as a dhcp client.
<PaulFertser>
hadis: if you want to deviate from default upstream config the solution usually is writing a uci-defaults script, and placing it in files/ . You're self-building anyway from the sources so you do not need Image Builder to repack your firmware.
<hadis>
ah, right! I'll look into that, thank you
<hadis>
PaulFertser: I did not get spi working! I'm currently stuck on `spi-mt7621 10000b00.spi: cs2 >= max 2` in the kernel logs. I did find this:https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-controller.yaml (cs-gpios section) and notably:"If that property is used, the number of chip selects will be increased automatically with max(cs-gpios, hardware chip selects)."
<PaulFertser>
hadis: but for upstream submission it should just be the same as many other single-interface devices, do not include the uci-default script when sending a patch to OpenWrt please.
<hadis>
PaulFertser: That's what I was wondering about too. This port is useless with the default configuration..
<PaulFertser>
hadis: I'll look the spi error up now, hold on.
<hadis>
No you hold on!
<hadis>
I think reiterating it solved the problem
<hadis>
I completely overloocked the <0> in the `cs-gpios` definition!!
<hadis>
That is the hardware cs!
Ansuel_ has joined #openwrt-devel
<PaulFertser>
hadis: :D
<hadis>
I think it has to look like this for me: `cs-gpios = <0>, <0>, <&gpio 4 GPIO_ACTIVE_LOW>, <&gpio 5 GPIO_ACTIVE_LOW>;` I'm just not sure on that `&gpio`, grepping for `cs-gpios` also shows definitions like `cs-gpios = <&qcom_pinmux 20 GPIO_ACTIVE_HIGH>;` So maybe I should be using &pinmux?
<hadis>
this is the dtsi file with all the aliases
<PaulFertser>
hadis: what & are you using for LEDs?
<PaulFertser>
hadis: I think it's just &gpio and should be &gpio here too.
<hadis>
`gpios = <&gpio 44 GPIO_ACTIVE_LOW>;` right, so it is &gpio !
<hadis>
I will try flasing it now!
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel_ is now known as Ansuel
<hadis>
I will disconnect when I change my IP for tftboot, be right back
<hadis>
I'm starting to understand the dts files much more now
<hadis>
I'm sort of confident in this try!
hadis has quit [Remote host closed the connection]
hadis has joined #openwrt-devel
<hadis>
Well I'm getting other errors but I know how to fix them.
<hadis>
I will report back shortly!
<hadis>
PaulFertser: Meanwhile, is there really no way to include device specific configuration upstream?
<PaulFertser>
hadis: device specific goes to the 02_network
<PaulFertser>
hadis: you probably want to use "nas" profile, not a router.
<PaulFertser>
DEVICE_TYPE := nas
<PaulFertser>
Hm, not sure it's sensible, it just includes hdparm to busybox :)
<hadis>
Why is that not sensible?
<PaulFertser>
hadis: yeah, just use "basic" then the firewall won't be included.
<PaulFertser>
hadis: do you need hdparm gadget on this target? It's not really a NAS.
<PaulFertser>
hadis: so with firewall not included you just define the network interface as "wan", and it'll be using dhcp client and be accessible via ssh without configuratioon.
<hadis>
That would be exactly what I need. Wonderful
<PaulFertser>
Hm, one of the supported "nas" devices has ucidef_set_interface_lan "eth0" "dhcp" so it's lan and it's dhcp. So probably that can be accepted too.
<PaulFertser>
Same about oxnas.
<hadis>
out of curiosity, are the device types documented somewhere? I wasn't able to find them anywhere
<PaulFertser>
OK, so in this case it's ok for a "basic" profile device to use dhcp on lan.
<PaulFertser>
hadis: not sure, I just did "git grep DEVICE_TYPE" in the root of the repo.
<PaulFertser>
And then checked DEFAULT_PACKAGES in include/target.mk
<hadis>
I'm doing that already it's just taking a really long time
<hadis>
Alright!
<PaulFertser>
hadis: git grep is much faster than just grep, and it ignores build_dir, staging_dir etc.
<hadis>
Oh it really is much faster, instant even
<hadis>
Okay before I figure our how to set that option I will try the new image with hopefully working SPI. Be right back!
hadis has quit [Remote host closed the connection]
hadis has joined #openwrt-devel
Misanthr- has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
<PaulFertser>
hadis: sleep time for me now, see you later!
<hadis>
PaulFertser: I have all three devices showing up in /sys/.../spi_master/!!
<PaulFertser>
hadis: yay!
<hadis>
I did see an error regarding the touchscreen but progress is progress
<PaulFertser>
Indeed
<hadis>
PaulFertser: Good night! Thank you for all the help
<hadis>
I think I can try to figure out how toget the ili9431 to show up as /dev/fb0
<hadis>
Anyways, I will probably keep bugging you tomorrow :P