The contents of build_dir/target-mips_24kc_musl/linux-ath79_nand/linux-4.14.93/drivers/mtd/, including nand/Kconfig, didn't provide any insight about available NAND drivers for the qca95xx chips (qca9563, of particular interest to me). Yes, my branch is a bit behind, based on commit 62dadcb86c from January 19, 2019.
But it requires 4.19 to not have to backport pretty much the whole MTD and SPI subsystems_
Please re-spin the patch as soon as we have kernel 4.19 support. The approach was already NAK'ed upstream and I don't see much gain in adding the hack if the next major kernel in OpenWrt will provide a suitable solution.
Tried uploading an ath79 sysupgrade image from luci and command line for wr842nd/v1 and the upgrade aborted. Tried prebuilt image from snapshot and from self built image using imagebuilder and got same result.
"The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform."
Have used the prebuilt snapshot ath79 image for wr703 with no reported errors.
Am reluctant to try and force a sysupgrade on the wr842 device.
Tried searching the forum but haven't found anything that would suggest a way forward. Any suggestions on where to look/proceed?
edit: fixed typo, target device is wr842n/v1
Hi @jeff, @dioni21, are you trying to upgrade over an ath79 or ar71xx image?
I had the same issue with my WNDR3800 when I tried to upgrade over an ar71xx image, and the -F flag worked fine.
Hope this helps.
Interesting -- both of these problems are where the current image's sense of "its" device doesn't correspond with the report of the owner. Were these "official" OpenWrt builds, or a "community" build or the like?
(There is a facility in the build system to accommodate expected name changes, such as when the OpenWrt "name" for the device changes between releases or when moving from ar71xx to ath79.)
No, it's only necessary if BOARD_NAME differs between ar71xx and ath79, which it often does (device naming is an inconsistent mess in ar71xx, in some cases you also have historical precedence of images having been evolved from other devices, e.g. tl-wdr3600 and tl-wdr4300).
From a quick glance at target/linux/ath79/image/image.mk and picking the first one with SUPPORTED_DEVICES, the "new" name is buffalo_bhr-4grv and it should upgrade "smoothly" from a device that has an image for wzr-hp-g450h already flashed.
I'm wondering why are you hijacking this forum thread with support requests, this probably belongs to separate forum thread, IRC or at https://bugs.openwrt.org
Please stop recommending usage of sysupgrade -F to general audience on forums, unless that person has serial console access and ideally (s)he knows what (s)he is doing. This command can brick the router easily if flashed with the wrong image.
If there's a problem with upgrade from ar71xx to ath79, please report it on IRC, mailing list or at https://bugs.openwrt.org so it can be fixed, we want to provide seamless upgrade for everybody if it's doable. Posting this upgrade issues on forums might be easier for you, but it could be missed by the developers easily as well, since it's quite hard to follow every communication channel available.
Has anyone picked up where in ATH79 devicetree one would enable GPIO 26 and 27 by setting bit 18 in the bootstrap register (0x180600AC ) ( Onion omega, Arduino Yun, TP-link MR2020,mr3040 V2, wr703 and wr741nd-v4 uses these, there are probably others. )
There is a function in ar71xx ( example in mach-arduino-yun ) that sets bit 18 of the bootstrap register so that GPIO 26 and 27 can be used as GPIO.
t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
It doesn't seem to be set in any of the dts configurations i've found for the ATH79 port and I've found no references to the bootstrap register in the dts "tree" ( in ath79.dtsi, ar9330.dtsi, ar9331.dtsi or the device specific dts )
Outputs from io utility on the 2 ports are :
ar71xx : io -r -4 0x180600AC
180600ac: 0006220e (bit 18 set)
ATH79 : io -r -4 0x180600AC
180600ac: 0000220e ( bit 18 not set )
Would it make sense to place it in ar9330.dtsi as another pinmux entry or is there a better place in the tree to have this ?
I'm not sure which other devices use MDIO to speak to external switches/Phys which use the MDIO bus functionality of these GPIOs
Try to use just pinmux definition, for example:
Switching GPIO0 to CS1 on AR724X SoC:
...
...
/* Add this two lines to spi enum */
pinctrl-names = "default";
pinctrl-0 = <&enable_cs1_bit>;
...
...
&pinmux {
enable_cs1_bit: pinmux_enable_cs1_bit {
pinctrl-single,bits = <
/*
* Set AR724X_GPIO_FUNC_SPI_CS_EN1 BIT(13) to 1,
* i.e. enable hardware CS1 but it turn-off GPIO0;
* Formula: *addr = (*addr & ~sub-mask) |
* (value & sub-mask);
* Where: addr is 0x18000000 + 0x40000 + 0x28 is
* base address of AR724X GPIO functions;
* <addr_offset value sub-mask>
*/
0x0 0x2000 0x2000
>;
};
};
Configure GPIO11 to CS1 on AR934X SoC:
...
...
/* Add this two lines to spi enum */
pinctrl-names = "default";
pinctrl-0 = <&gpio11_to_cs1_bit>;
...
...
&pinmux {
gpio11_to_cs1_bit: pinmux_gpio11_to_cs1_bit {
pinctrl-single,bits = <
/*
* Set AR934X_GPIO_OUT_SPI_CS1 7 value to GPIO11,
* i.e. enable hardware CS1 but it turn-off GPIO11;
* Formula: *addr = (*addr & ~sub-mask) |
* (value & sub-mask);
* Where: addr is 0x18000000 + 0x40000 + 0x2C is
* base address of AR934X GPIO Output functions;
* <addr_offset value sub-mask>;
*/
/*
* 0x2c+0x8 addr_offset for GPIO11(Bit 31:24);
* 0x2c+0xc addr_offset for GPIO12-GPIO15;
* 0x2c+0x10 addr_offset for GPIO16-GPIO19;
* 0x7 value (with Bitwise Left Shift) for mux CS1
* use 0x8 value for mux CS2;
*/
0x8 0x7000000 0xff000000
>;
};
};
Link
Use your shift "addr_offset" regarding of base GPIO addres - It be different because, it depends on your platform!
Example:
For AR9330 - pinmux: pinmux@18040028 where the addr is 0x18000000 + 0x40000 + 0x28 is base address of AR724X/AR9330 GPIO functions.
Next, you need to shift to AR71XX_RESET_BASE (0x18060000) and your AR933X_RESET_REG_BOOTSTRAP(0xac) addres - (0x18040028-0x28+0x00020000+0xac=0x200D4).
should the offset not be 0x20084 ?
( 0x18040028 + 0x20084 = 0x180600AC )
is the offset /shift calculated from the base address of the GPIO functions ( 0x18004000 ) or from the address of the pinmux entry as in the dts " pinmux: pinmux@18040028... " - it points to GPIO_FUNCTION_1
I've added the pinmux snippet and it compiles without issue but it doesn't set the bits as expected, could this be because offset is larger than the the pinmux "size" of 8 , but we're asking it to jump a lot further than that.
should map to a valid range of 0x18040028 - 0x1804002F which seems to cover the general GPIO mux and settings registers GPIO_FUNCTION_1, GPIO_IN_ETH_SWITCH_LED and GPIO_FUNCTION_2
( only realized now I'm using the datasheets form your github repo, thank you for those... )