<KanjiMonster>
stefanct: I think the issue is that the cpu clock has the xtal clock as its parent, but is registered before the xtal clock. So when the core tries to recalc the rate, the parent doesn't exist yet, so the parent rate passed is 0. On later registration of the xtal clock, it should redo the rate calc with the actual rate, so the warning should be harmless
<SnarlingFox>
robimarko: Hi buddy, I'm finally have a little time to start looking at that WSQ50 rebase (https://github.com/openwrt/openwrt/pull/14028) over the next day or so - don't wanna assume you're free so please let me know when you've got a few mins to discuss :)
<robimarko>
SnarlingFox: Hi there, what do you want to discuss?
<SnarlingFox>
The most recent build in that PR is not quite stable - I've been using it now on 4x WSQ50's and aside intermittent performance issues over wireless. Changing from 2.4 GHz to 5 GHz can sometimes help. I've ended up creating a slew of SSID's on each band just to be able to connect to them individually (my neighbours hate me..)
<SnarlingFox>
In addition to that, one particular WSQ50 is connected to my CCTV NVR in the loft as a bridge, that unit is highly unstable and stops responding often (1-2 times daily), I've had to put a smart plug on it just to be able to remotely power cycle it. It's constantly got CCTV traffic going through it (7 cameras) to another location on my home network. The factory firmware was far more
<SnarlingFox>
stable, once per week I'd perhaps have to power cycle it.
<SnarlingFox>
And by stop responding I mean even the UART stops responding too. I've slipped an ESP32 inside that WSQ50 functioning as a WiFi to Serial gateway so I can remotely poke it.
<SnarlingFox>
Sadly the ESP32's SRAM isn't large enough to capture the entirety of the dump that gets spat out to the UART when it freezes. Suppose I could code some kinda syslog forwarder on it, but sometimes there's no log output at all. Just eadlock.
<SnarlingFox>
The glimpses I did get sometimes pointed to the ETH subsystem as we as the wireless subsystem - my guess is there's some packet coming out from the CCTV NVR that it can't handle and craps itself.
<robimarko>
It worked fine before?
<robimarko>
It would be interesting to see the stack trace when it panics
<SnarlingFox>
Sorry, I realise that was a massive dump of text
<mrkiko>
robimarko: seen your work on RB5009; congrats and thanks a lot
<robimarko>
:)
<SnarlingFox>
Back on the factory firmwares general WiFi performance was very good and the WSQ50 connected to the CCTV NVR would perhaps lock up once every 7-10 days. Since swapping to OpenWrt, overall WiFi performance is "variable" and the WSQ50 on the CCTV locks up daily.
<mrkiko>
robimarko: wondering how you managed to modify the routerboot binary
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
wcyb has joined #openwrt-devel
<wcyb>
Hi, I have encountered a problem and cannot find a solution. Maybe someone will know what I am doing wrong. Generally speaking, using the latest stable U-Boot, I want to run the latest stable OpenWRT on a supported SoC (QCA9533).
<wcyb>
U-Boot works, the OpenWRT build system completes without errors, however, when I try to boot the generated image (sysupgrade), U-Boot displays a "Bad data CRC" error. Is the build system doing something to do with this? I base my device configuration block on $(Device/Default).
goliath has quit [Quit: SIGSEGV]
<mrkiko>
sysupdate is not generally meant to be used with u-boot unless special support added to u-boot
<rmilecki>
robimarko: impressive Mikrotik work
<rmilecki>
nice!
<robimarko>
rmilecki: It only took 2 years
<mrkiko>
yeah, I am tempted to try the rb5009 as well
<wcyb>
Ok, however, when I use the initramfs image, U-Boot displays a "Wrong Image Type for bootm command" error, even though it has a header like the sysupgrade image. Is there perhaps an example I could follow if I want to add support for a "clean" device with an official, unmodified U-Boot and OpenWRT?
<mrkiko>
wcyb: hoping someone can help you.
<mrkiko>
wcyb: matbe pepe2k's ubootmod could help?
<mrkiko>
wcyb: you're in the ath79 world right?
<wcyb>
mrkiko: Yes, ath79, I know this mod from pepe2k, however, my goal is to use the latest stable U-Boot.
<wcyb>
The current issue I'm trying to solve is the one with the CRC of the data, and I was wondering if maybe some script is modifying the image after it's created, which could be causing this problem.
dermoth has joined #openwrt-devel
dermoth has quit [Remote host closed the connection]
dermoth has joined #openwrt-devel
goliath has joined #openwrt-devel
f00b4r0 has quit [Quit: reboot]
<wcyb>
mrkiko: There is progress. Actually, the CRC of the data was different from that generated by the OpenWRT build system, and after I corrected the CRC of the data and header by U-boot's built-in crc32, the problem disappeared. However, another one appeared - during image decompression: "lzma compressed: uncompress error 1". This is followed by a board reset.
<wcyb>
mrkiko: I managed to solve the problem. It turned out (I still have to make sure) that either the SPI memory was defective and this was causing CRC problems, or the default read frequency in U-Boot was too high. Either way - OpenWRT is working. Thanks guys.
<russell-->
jow: i found that when while hacking on luci and tried moving the encryption and key entries in the Wireless Security tab to the General Settings tab (to try to simplify things for naive users), saving doesn't work. i suspect that whatever is saving those values can't find them in the new location.