ath79: add support for Joy-IT JT-OR750i #4293
Conversation
| @@ -225,6 +225,12 @@ glinet,gl-x750) | |||
| hak5,lan-turtle) | |||
| ucidef_set_led_netdev "wan" "WAN" "orange:system" "eth1" | |||
| ;; | |||
| joyit,jt-or750i) | |||
| ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0" | |||
There was a problem hiding this comment.
@adschm The new bootloader sets GPIO MUX functions for the LAN/WAN ports' LEDs to blink. From what I heard it was preferred to reset the GPIO MUX registers and let kmod-ledtrigger do the work. Actually I've thought this was default in OpenWrt, but they are not. That's why I didn't realize the WAN-LED assignment was wrong. How shall this be handled? As the LEDs are integrated in the ports I don't expect anyone wanting to reassign them. Therefore I'd like to remove the GPIO network port LED definitions completely to save some CPU cycles...
There was a problem hiding this comment.
@blocktrron Do you have a clue how to handle this? From what I remember the GPIO MUX functions were resetted previously in ath79. Momentarily they are not. I'd prefer letting the MUX do the blinking. Is it okay to remove the port LED definitions or will OpenWrt eventually reset the GPIO MUX functions in the future again?
@s-2 You once showed me an ath79 board where they set the switch LED_BLINK and GPIO MUX registers from the DTS. Which was it? I think that would be an alternative approach so that when OpenWrt decides to reset the MUX register again, it won't break this board...
There was a problem hiding this comment.
You once showed me an ath79 board where they set the switch LED_BLINK and GPIO MUX registers from the DTS.
Regarding the GPIO settings on the SoC side: the &pinmux node in qca953x.dtsi is set to 0x1804002c, i.e. the start offset of GPIO_OUT_FUNCTION0; e.g. in compex_wpj531-16m: <0x8 0x2b000000 0xff000000> means GPIO 11 (in GPIO_OUT_FUNCTION_2) is set to 43: LED_LINK (for port 2) etc.
Many other devices just write values to 0x0 to restore normal SoC GPIO function (overriding bootloader defaults, e.g.
pinctrl-single,bits = <0xc 0x0 0x00ff0000>;).
However, I can't seem to find devices changing LED registers of builtin_switch though, there are only initvals for external ar8327-switches (a few devices declare pinmux in the builtin_switch node, but that again refers to SoC regs eventually).
Technically, they should be accessible though, by writing pinmux entries for switch registers 0xB0, 0xB4, 0xB8, 0xBC.
Not sure if those are the ones you mean? (they are 32 bit registers, accessible via tunneling of two 16 bit commands through MDIO), while there are also LED_CONTROL rules //edit: these are just the names of 16bit fields within those (32 bit) switch registers.
However, apparently none of these are ever written from any dts though...
//edit: looking at the ag71xx source, builtin-switch; from dts is only used to determine default clock speeds etc., can't find any dt bindings for pinmux though.
There was a problem hiding this comment.
@s-2 Yes those are the registers I was referring to...
I'd prefer then to set the MUX registers in the DTS to reflect the bootloader's configuration and completely remove the GPIO LED definitions for the port LEDs. I think it is a waste of CPU cycles to trigger them and I can't figure out a reason someone wants to control them manually.
comes with bootloader and ART? also, include in Specification as many things as you can like: |
CodeFetch
force-pushed
the
patch-9
branch
2 times, most recently
from
197d43b
to
6ea2072
Compare
|
@blocktrron FYI, since you made a similar patch a few years ago ... |
Yes, the manufacturer calibrates the router with their firmware and installs the Joy-IT bootloader afterwards and wipes the firmware partition. |
|
Here's a newer version of the bootloader: It can be flashed on the old bootloader's failsafe web interface under /bootloader_en.cgi |
Well, replacing bootloader should not be necessary to get a device supported, at least not on ath79 target. Anyway, this leads to the obvious question about this device: Has it ever been sold regularly? Because otherwise, OpenWrt will probably not add it as a supported device. |
Some Freifunk communities have been getting a few devices for testing with old bootloaders and were made aware that these probably need an update before being officially supported. (Theirs are called JIT-OR750i if that makes a difference)
The final devices for sale are on their way to Europe since 2 months (shipping delay) and will be sold soon. |
that's also good info for the commit message, so the context of "bootloader only" is better understood |
I don't think people will assume that there is no ART partition. Actually I wondered what you are referring to 😀... You can compare it with a mini computer like Raspberry Pi which comes without OS, too. There is a usage agreement which states that one must make sure that the OS complies with legal regulations. So it's quite open... |
|
maybe it's just me thinking of the noobs out there. I tend to think the longer the commit message the better 😄 |
|
@mpratt14 It shall be noob-friendly. We are going to create a very detailed Wiki article. |
|
I think this is ready for merge now. The device will be sold tomorrow.
|
This will be a problem, since I don't think many people are keen on starting "mixed support" again... |
|
@adschm What shall we do then? Change it for all qca988x-devices? |
|
@adschm It would be nice to have this router in the next release. Ben Greear recommends himself to use the official ath10k driver on these platforms. So shall I open a pull-request for changing them? Are there any other issues with this PR? |
|
I've created a pull-request: |
|
@adschm I've changed the driver to the Candelatech version. Can it be merged now? |
He have not even finished 21.02 yet, so there should be plenty of time until the next release. |
|
@adschm What do you mean? 21.02-rc4 or a 21.02 stable is the next release, isn't it? And simple device support will be backported in most cases, won't it? So what's missing here? |
By default, most devices are indeed not backported to the current work-in-progress release, after branching off master. In any case, the process would be
|
|
@s-2 I just think it would be very nice for a device which openly endorses OpenWrt to be supported right from the beginning, because I don't like that they offer self-built images... |
|
unfortunately, a clean backport is no longer possible, because master has the new way to define art partition and 21.02 does not so either an edited commit or an extra commit to make that change for backporting any difference like this would be something that needs review again |
|
@mpratt14 Can you point me to a commit? I don't know what you are referring to. I don't have a problem to make a backporting request PR, but I think it should be merged in master first... |
|
I mean this, I guess it is not the partition exactly but for the MACs, this is in master but not 21.02 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=abc17bf306acd1c5954fbba97134e891439f917c but either way master branch is first like you said |
|
@mpratt14 Ah I didn't see that. Thank you. I have updated the PR accordingly. |
Specifications: * QCA9531, 16 MiB flash (Winbond W25Q128JVSQ), 128 MiB RAM * 802.11n 2T2R (external antennas) * QCA9887, 802.11ac 1T1R (connected with diplexer to one of the antennas) * 3x 10/100 LAN, 1x 10/100 WAN * UART header with pinout printed on PCB Installation: * The device comes with a bootloader installed only * The bootloader offers DHCP and is reachable at http://10.123.123.1 * Accept the agreement and flash sysupgrade.bin * Use Firefox if flashing does not work TFTP recovery with static IP: * Rename sysupgrade.bin to jt-or750i_firmware.bin * Offer it via TFTP server at 192.168.0.66 * Keep the reset button pressed for 4 seconds after connecting power TFTP recovery with dynamic IP: * Rename sysupgrade.bin to jt-or750i_firmware.bin * Offer it via TFTP server with a DHCP server running at the same address * Keep the reset button pressed for 6 seconds after connecting power Co-authored-by: Sebastian Schaper <openwrt@sebastianschaper.net> Signed-off-by: Vincent Wiemann <vincent.wiemann@ironai.com>
No. https://openwrt.org/docs/guide-developer/device-support-policies#backports |
|
Merged to my staging tree - thanks! Regarding a backport: I'll push one to the upcoming 21.02 branch, hopefully rc builds will be available in a reasonable timeframe. WIth the device being targeted to a broad audience specifically for use with OpenWrt, which is not necessarily familiar with OpenWrt, having builds with a working package repository are desirable. I think this justifies it enough. |
|
Built an image with this patch, but it does not boot: |
|
Panic was not related to this PR, temporarily fixed in bd521f2 |
|
I've prepared a 21.02 backport for this device, please report if it works as expected on the production unit: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/openwrt-21.02 |
|
@blockttron Thank you for catching the issue with the swapped switch LEDs! They were mirrored... I didn't see it, because the new bootloader's values were not overridden. I've tested the OpenWrt master. Looks good. |
|
@blocktrron The backport tree also works... |
Specifications:
Installation:
TFTP recovery with static IP:
TFTP recovery with dynamic IP:
Co-authored-by: Sebastian Schaper openwrt@sebastianschaper.net
Signed-off-by: Vincent Wiemann vincent.wiemann@ironai.com