<will[m]>
hmm i don't see any reference to "START=" on the wiki but i do see stuff about prefixing your uci script with xxx_ where xxx is an alphabetical run order
<wulfy23>
you want to get rid of stuff in rc.d
<wulfy23>
uci-defaults runs from boot which has a START of 10
<will[m]>
ok i'm just unfamiliar with START as a boot order thing so i'm unsure how to make that change
<wulfy23>
you don't you drop your script in /etc/uci-defaults
<will[m]>
cool did that
<wulfy23>
if what it does effects scripts that start later then 10... then you are ok
<will[m]>
ohh
<will[m]>
currently i have it trying to remove two rc.d/S00* scripts plus a bunch of others but maybe i can live with them
<will[m]>
orrrr i could be evil and create a files/etc/rc.d/K00nuke_from_orbit script
<wulfy23>
too late... remove them from the respective package or hack rootfs.mk
<will[m]>
oh i see, rootfs.mk runs all the postinst and rc.common * enable scripts. i wonder why that didn't show up in my grep before now
<hurricos>
LS1034A, looks like 6 x M.2 E-key, 5 ports
<hurricos>
RT8188 x 2 integrated
<will[m]>
oh while i have you / that's running, is there a decent guide on booting openwrt from sd card? i have this gl.inet router and i'd rather avoid killing its embedded flash with all my tests if i can avoid it. i've found some uboot wizardry like this, but not confident enough to attempt any such commands until i dig more: http://wiki.micromint.com/index.php/Boot_from_SD/MMC#Booting_from_the_microSD_Card
<hurricos>
PoE, Atheros 8035-AL1B
<wulfy23>
thats all bootloader dependant, best way to get confidence is to try stuff, fail, and keep trying
<wulfy23>
find some good guides and see what works
<will[m]>
pretty cute, love pole-mounted wifi
<wulfy23>
BPI boards are probably the reference for fancy sdcard boot stuff
<will[m]>
i do know GL uses uboot i guess the big question is how to just say "see /dev/mmcblk1? yeah that"
<will[m]>
ok
<wulfy23>
all depends what they have compiled into their uboot
<wulfy23>
most wont add whats needed... so chainloading / bootstrapping would be needed
<will[m]>
gotcha
<will[m]>
mmmmmm fun
<will[m]>
oh good thing i didn't run this as root, rm -rf /etc/rc.d instead of rm -rf $(1)/etc/rc.d would've hosed my laptop
<wulfy23>
if all you want to do is minimise wear and tear... just compile mmc support into the kernel and just from there or from block-mount
<wulfy23>
too much hassle to do it all from uboot if its not supported
<will[m]>
i do know that gl-mv1000 touts its -sdcard- compatibility in the firmware filename itself
danitool has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
wulfy23 has quit [Remote host closed the connection]
<digitalcircuit>
I'm getting "cpufreq: __target_index: Failed to change cpu frequency: -5" shortly after "cpufreq: notification 0 of frequency transition to 1725000 kHz", so whenever the CPU attempts to hit max clock, something about the L2 cache boosted voltage is resulting in an error. I'm still trying to figure out what else I need to change.
<digitalcircuit>
"/sys/kernel/debug/regulator/regulator_summary" shows "s1a" correctly has a max of "1175mV", which it didn't before. I'm not sure if I need to change "s1b" as well, perhaps, or if there's some other table I'm overlooking.
<digitalcircuit>
My current guess is ALSO boosting "s1b" to "regulator-max-microvolt = <1175000>;" despite it not being shown as connected to anything (l2-cache is set to "l2-supply = <&smb208_s1a>;", not touching s1b), and.. I'll see from there.
<digitalcircuit>
(I'll be sure to submit my patches to the "master" branch, then work on a backport to 21.02; I'm just testing on 21.02 because stress-ng.. well, it used to build there until a recent package update.)
<will[m]>
wulfy23: that rootfs.mk hack worked perfectly thank you
<will[m]>
i'd like to add my openwrt boot log and other details to the gl-mv1000 wiki page, could i get an account?
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #openwrt-devel
<wulfy23>
cool good luck with it... afaik there is a thread on the forum for new wiki accounts if nobody is here
<mangix>
was there a branch to use the upstream ag71xx driver for ath79?
<digitalcircuit>
Belated, nevermind the "s1b" aspect, that doesn't make any sense (it's reported at 1050mV when s1a is 1100mV, so I don't think that regulator's related at all. Something else must be making the modified L2 1.4 GHz speed/voltage combo invalid with CPU clock too.
* digitalcircuit
adds the missing ")" to his remark
<digitalcircuit>
When Ansuel mentioned to "tweak the OPP table and increase your CPU voltage", this seemed a lot simpler than I expected. Unless.. they meant actually changing CPU voltage, not L2 cache voltage..?
<digitalcircuit>
Hrm.
<will[m]>
wulfy23: do you think it's worth updating that "using the image builder: removing useless files from firmware" wiki page with this rootfs.mk hack ?
<wulfy23>
actually... i left that there just for reference even tho its obviously circa chaos chalmer days
<wulfy23>
i'm sure most would advise it be removed but I think for anyone at this level
<wulfy23>
it's enough to give them ideas...
<wulfy23>
if you want to add a section above with how you did it... then that is likely better
<wulfy23>
then for sure remove it
<will[m]>
ok
<wulfy23>
what I liked about that sample is they used a CONFIG symbol for the mod which was cool
<wulfy23>
kindof an inverse 'files'
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
Rentong has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Rentong_ has joined #openwrt-devel
Rentong has quit [Read error: Connection reset by peer]
<wulfy23>
correction... hadnt looked at it in a while... they used a VARIABLE to define a removelist file which is even cooler
<Tusker>
heya guys, on ath10k, on a device I am porting (not in master yet), the radios come up, but they don't seem to have any signal power (iw wlan0 scan - shows nothing) Are there any tricks that are known to get it working ?
<slh>
Tusker: you are extracting ART/ loading it?
<Tusker>
slh: it isn't in ART... factory firmware loads the precal from file
<Tusker>
i have loaded the same exact file as precal, which is why the radios come up
<Tusker>
let me try and swap the 2g and 5g... they are both 9980's so maybe that's it
dedeckeh has joined #openwrt-devel
<Tusker>
ah ha
<Tusker>
that did it
<Tusker>
sorry for the noise
valku has quit [Remote host closed the connection]
valku has joined #openwrt-devel
swegener has quit [Quit: leaving]
swegener has joined #openwrt-devel
Rentong has joined #openwrt-devel
<digitalcircuit>
ipq8065/NBG6817 minor note - I apparently have a Qualcomm ipq8065 SoC that's in "PVS bin" #2, as per "cat /sys/kernel/debug/opp/cpu0/opp\:1725000000/supply-0/u_volt_*" matching up with the "opp-microvolt-speed0-pvs2-v0" DTSI microvoltage values specified within the "opp-1725000000" entry of CPU frequency "opp_table0"...
<digitalcircuit>
I'll reset the L2 cache voltage to default and try *slightly* raising the CPU voltage (raising all values by 10000 microvolts, e.g. 1200000 -> 1210000), and hopefully I don't break anything. (Ansuel hadn't mentioned how much they had raised the CPU voltage to have more stability; trial and error it is!)
goliath has joined #openwrt-devel
<Tusker>
digitalcircuit: you might need to stress test it a bit on each voltage
rua has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Tusker: Just to clarify, by "each voltage", are you referring to the full range of minimum to maximum in the "opp-microvolt-<name>" parameter list, so somehow forcing it to only minimum, to only center value, then to only maximum?
wulfy23 has quit [Remote host closed the connection]
<Tusker>
well, you are intending to raise the voltage slightly, to improve stability
<Tusker>
raising the voltage will increase the heat etc, and should be pretty safe for such minor increments
<Tusker>
but, using some form of stress test, maybe streaming 1gbps traffic through it with cake or something should stress it enough to know if the voltage is high enough
abiliomarques has joined #openwrt-devel
HuShuai has joined #openwrt-devel
<digitalcircuit>
You've clarified this, and what you've said makes sense.
<digitalcircuit>
Noted! I wasn't sure if you meant I should try to override the "get_krait_bin_format_a/b()" functions to e.g. use the noticeably higher voltage PVS bins #1 or #0 ("opp-microvolt-speed0-pvs1-v0", etc). That seemed.. a bit more risky to jump that far at once (I'll probably treat PVS bin #1 as my upper bound of "if I raise CPU voltage to this much, it isn't helping").
<digitalcircuit>
Thank you for the ideas, too! I suspect a combination of iperf3, "normal" CPU stress (openssl bench?), and the Deja Dup SFTP backup of ~200 GB test case (which is what causes it to currently semi-reliably hard reboot) makes sense. I've been bitten by thinking I've fixed the issue only for 5 Deja Dup SFTP runs later for it to hard reboot and corrupt the backup.
dedeckeh has quit [Remote host closed the connection]
rsalvaterra has joined #openwrt-devel
Tapper has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
brpr has joined #openwrt-devel
<brpr>
Hello everyone, I've tried to ask the main channel (not knowing that this channel existed) about this yesterday but my internet went out. I'm trying to get OpenWRT ported to the ASUS RT-AC55U and the partition layout has stumped me. There are 11 partitions, while some of them are recognisable like uboot or rootfs, I can't see the art partition! Will I need to dump the firmware? I do have the GPL'd source from the ASUS s
<PaulFertser>
brpr: you left too fast
<PaulFertser>
brpr: what SoC is used by that target?
decke has joined #openwrt-devel
<mrkiko>
digitalcircuit: I admite you for your work and persistence, and read your mails in ml - awesome
<brpr>
PaulFertser: yeah, I'm sorry. I'm currently moving houses and the internet keeps cutting out. I'm gonna need to disassemble it again as the wiki article is quite inconsistent
Rentong has quit [Ping timeout: 480 seconds]
<PaulFertser>
brpr: isn't there a wikidevi entry? And if you already have a full log of vendor firmware, can't you just look in there?
HuShuai has quit [Remote host closed the connection]
<mrkiko>
brpr: ath79 then?
<brpr>
I've looked into the wikidevi entry and it has a different SOC then my unit. Mine is a QCA9882 while deviwiki lists the QCA9557
<PaulFertser>
brpr: have you already shared full serial log for your board somewhere public?
<mrkiko>
brpr: different versions; quite different I guess?
goliath has quit [Quit: SIGSEGV]
<mrkiko>
brpr: and if you happen to feel like helping me with my R6100, feel free to ask :D :D
<brpr>
PaulFertser: Not yet. I still have yet to recieve my serial adapter because well, Poland and its shipping :)
<PaulFertser>
brpr: so what kind of access have you got currently?
<PaulFertser>
brpr: sharing dmesg alone can be helpful too if you want answer to your question.
rsalvaterra has quit [Quit: Leaving]
<brpr>
currently sadly I've got only the serial pinout (yeah, I know) and a Raspberry Pi. That actually kinda struck me - could I use the Raspberry Pi for reading serial and accessing the U-Boot console?
<PaulFertser>
brpr: of course you could if the target has 3.3 V UART.
<brpr>
Alright, I'm going to have to dig it up from the moving boxes - sorry for my lack of knowledge - I haven't messed around with Pis in years - since like 2016
<Tusker>
yeah, raspberry pi is usually fine for serial
<Tusker>
9882 is the wifi chip, the soc should be the 9557 still
<brpr>
oh, oops. no wonder why that shield was the easiest to pop off :D
<brpr>
alright, I'm going to go searching for my Pi
<Tusker>
should be a doable port, https://github.com/drag0njoe/RT-AC55U seems to exist for the GPL source, which would include all the necessary board oddities
<brpr>
yep, I've got the source on my PC but I don't know where to start with it. I've found my Pi, now to just hook her up
<Tusker>
but, you might get away with booting the most similar ath79 target via tftp and work from there
<PaulFertser>
brpr: you'll need to run raspi-config or something to enable serial but disable console on it. Then you can use picocom or minicom or whatever you prefer. Don't forget Tx goes to Rx.
<brpr>
thanks for the tips! I'm going to go solder some wires on so I'll be right back in like 5 minutes.
<brpr>
Please choose the operation: 1: Load System code to SDRAM via TFTP. 2: Load System code then write to Flash via TFTP. 3: Boot System code via Flash (default). 4: Entr boot command line interface. 7: Load Boot Loader code then write to Flash via Serial. 9: Load Boot Loader code then write to Flash via TFTP. L: Load LSDK NART firmware, write to Flash via TFTP and reboot. 0 3: Boot System code via
<brpr>
Noooo! I'm once again getting garbage!
<PaulFertser>
Hm, maybe no, that zyxel is nasty
<brpr>
PaulFertser: what should I do now? I'm back to clear reads after isolating the wires
<PaulFertser>
brpr: " Load System code to SDRAM via TFTP"
<PaulFertser>
mrkiko: for the reference, you can always git grep for a compatible string (in this case qca,ar8229) either in OpenWrt git (if it's not yet upstream) or in Linux git.
<mrkiko>
PaulFertser: thanks a lot!!
<brpr>
PaulFertser: anything I could do?
<brpr>
still not working
<PaulFertser>
brpr: show logs from host side
<PaulFertser>
brpr: oh idk, boot windows and use the windows tftp server recommended on openwrt.org wiki ;)
<brpr>
:(
<brpr>
i'll do it
<PaulFertser>
brpr: are you sure you're not too tired or somehow else not fully capable atm? You sounded rather different in the morning.
<PaulFertser>
Not being able to interact with your terminal directly it's hard to give fully meaningful suggestions you know.
<brpr>
haha I'm good, it's just my desk being cluttered and OpenSUSE not having any syslogs
<PaulFertser>
So sorry but not sure what exactly might be wrong. When I get that puzzled I'm always resorting to strace.
<PaulFertser>
And then if e.g. strace shows me nothing is happening with in.tftpd process then I know it must be something else that accepts the connection. If I see it really accesses the file but gets the error then I'm using "ps -eo pid,euid,egid,command" or something like that to see what real UID and GID the process is using. Then if it's all proper I'll start checking SELinux / apparmor settings or
<PaulFertser>
POSIX
<PaulFertser>
ACL (but that's visible in ls -l output and apparently not your issue).
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<brpr>
PaulFertser: we're booting OpenWRT!
<brpr>
PaulFertser: We're in!!!
<Habbie>
woop!
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
<PaulFertser>
brpr: oh wow
<PaulFertser>
brpr: what was wrong?
<brpr>
I used Windows :P
Rentong has joined #openwrt-devel
<brpr>
PaulFertser: what's next? I'm in OpenWRT
<PaulFertser>
brpr: huh, it was a silly joke of mine, I didn't mean to recommend using windows for real.
<Habbie>
haha
<PaulFertser>
brpr: What I would get working first would be NAND and then wireless. So you can check how that zyxel board enables NAND, add that to your DTS, make partitioning match what you obtained using vendor's firmware, then change wifi section to reference "caldata" partition.
<brpr>
PaulFertser: uhm... alright - could you at least help point me in the right direction?
<PaulFertser>
Another unrelated task is figuring out the wired ethernet settings, probably you can just try some from similar boards to see what works for that.
<brpr>
caldata - I think that's in device tree
<brpr>
also wired ethernet works
<PaulFertser>
brpr: see e.g. target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts same SoC as yours but with NAND enabled.
<PaulFertser>
Of course you'll need to use a different partitioning for your board, making it match the vendor firmware.
<brpr>
alright
<brpr>
I'm taking a break lol, doing two things at once is stressful
<PaulFertser>
brpr: in other boards &wmac { mtd-cal-data } option refers to "art" but you'll want it to refer to "caldata" instead.
<brpr>
Ok. Any other commands I need to run in the WRT shell?
<stintel>
nbd: is the format expected by uhttpd json_script redirect handler documented somewhere ?
<PaulFertser>
If your device is dual band you'll want to check hexdump -C for the caldata partition to determine the offsets for ath9k and ath10k cards.
<brpr>
oh yeah it is
<brpr>
2.4 and 5 GHz
<brpr>
PaulFertser: hexdump -C seems to freeze, should I wait?
<PaulFertser>
brpr: no, press Ctrl-D
<PaulFertser>
brpr: it expects a file name.
<brpr>
:P shouldve known
<PaulFertser>
brpr: I can't tell you any specific commands, it's hard to teach Embedded Linux in few IRC messages
<brpr>
oh yeah, no problem. I've mostly been dealing with desktop
<PaulFertser>
brpr: I also suggest to look at any recent commit adding new devices, e.g. 55b4b3655263984b92e4b9fc515a5e6b8003c655 to see what it usually takes to add a new board.
<PaulFertser>
brpr: for NAND devices OpenWrt expects you to have a flash partition called "ubi". And that partition will be formatted as ubi and one of its volumes will be called "rootfs".
* enyc
meeps
Rentong has joined #openwrt-devel
<brpr>
PaulFertser, So wait - the UBI_DEV partition is going to be rootfs? What about the "rootfs" partition?
<PaulFertser>
brpr: I think this /proc/mtd is confusing. You should look at what the kernel printed in dmesg. Because some of these partitions you see in /proc/mtd are inside the other mentioned partitions.
Rentong has quit [Remote host closed the connection]
<brpr>
Now I see some UBI partitions - nvram,Factory,Factory2,linux,linux2,lsdk,jffs2
<brpr>
PaulFertser, there is no rootfs partition in the ubi partition
<PaulFertser>
brpr: if linux is inside UBI then how u-boot is able to find it?
<PaulFertser>
brpr: reg not correct, should be reg = <N M>; where N is offset, M is size.
<brpr>
PaulFertser, alright. so like reg = <0x000000000000 0x0000000e0000>;?
huaracheguarache has joined #openwrt-devel
<huaracheguarache>
If I want to backport a patch from netdev that's not been merged in mainline yet, do I place it in the backport or pending directory?
<brpr>
Alright. I won't bother with GPIO YET as I see a Power LED (however the incorrect one). How would I proceed from here?
lucenera has joined #openwrt-devel
<brpr>
PaulFertser, Do I need to make another image and see if the partitions mount now?
<PaulFertser>
brpr: yes
<brpr>
Alright. Making it now.
<brpr>
PaulFertser, I have touched the target makefiles but the board doesn't show in make menuconfig.
<PaulFertser>
brpr: try to "rm -r tmp/" to regenerate all data about the targets.
<brpr>
Hmm, still nothing.
<PaulFertser>
Then look at "git diff" to see if you might have missed something.
<brpr>
I don't get anything there...
<PaulFertser>
Then it means you didn't modify anything :)
<brpr>
But I did. If i ls in the ath79 dts directory and grep asus it gives me my new file
<brpr>
"qca9557_asus_rt_ac55u
<brpr>
oh wait
<brpr>
I'm stupid
<brpr>
I didn't add the file extension
<PaulFertser>
brpr: but you didn't add to image/Makefile instructions for building images for that board.
<brpr>
That too. Only now reading the wiki entry about this.
Rentong has quit [Ping timeout: 480 seconds]
<brpr>
I'm sorry once again PaulFertser but how exactly would I go to adding the board to the makefile?
<PaulFertser>
brpr: please see recent commits that were adding new devices.
danitool has joined #openwrt-devel
linusw has quit [Quit: Connection closed for inactivity]
chwba has joined #openwrt-devel
<brpr>
I did it PaulFertser! I based my makefile entry on the Zyxel one but if we get all things work I'll tweak it for the router.
<brpr>
I just changed the device model and name
<PaulFertser>
brpr: I'm not quite sure the initramfs image made with the zyxel entry will be good, I see some strange packing procedures for that zyxel.
<brpr>
It worked before (that's the image I booted once through TFTP)
<digitalcircuit>
It turns out the OPP triplets are <target min max>, NOT <min target max> like one would expect. So https://github.com/openwrt/openwrt/commit/1e25423be8acb38e979cd5a38abb1ca4cac2837e introduces a regression by reducing the CPU voltage for ALL ipq8065 CPU frequency levels. I might want to file this as a new merge request before I actually fix the crash.
<digitalcircuit>
mrkiko: Thanks!
<digitalcircuit>
(No need to wait up for me, if someone wants to make this a pull/merge request right now, feel free! But I'll get to it eventually :)
<digitalcircuit>
(And yes, I'll file on the "master" branch first - backporting is more manageable than forward-porting.)
dedeckeh has quit [Remote host closed the connection]
jbowen has quit [Ping timeout: 480 seconds]
<hauke>
mangix: thanks
jbowen has joined #openwrt-devel
KGB-0 has joined #openwrt-devel
slh has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
slh64 has quit [Ping timeout: 480 seconds]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
<mangix>
hauke: I'm working on a gdb version update that reworks a bunch of the patches. Will obsolete the patch in that branch
<mrkiko>
hauke: Hello! After some efforts I managed to get the "io" package working, and
<mrkiko>
hauke: got a different DTS. Still same issue.
<dwfreed>
digitalcircuit: this is something only applicable to 21.02, right? ie, if I were thinking of getting an nbg6817, I wouldn't have the issues you're trying to fix if I stuck with 19.07
<mrkiko>
18070010: 00 00 ff ff
<mrkiko>
blogic_: ping
<digitalcircuit>
dwfreed: I *think* it's only applicable to 21.02. On 19.07, I still had random reboots with my NBG6817, but they weren't semi-reliably triggered by the issue I'm having on 21.02+.
<digitalcircuit>
On testing: raising the CPU voltage at 1.75 GHz from 1200000 microvolts to 1220000 uV has not helped. Time to raise the other high-ish frequency too (1.4 GHz CPU), then failing that, raise all by another 20000 uV...
<digitalcircuit>
It's also a niche case (OpenSSH SFTP backup to USB 3.0 external HDD plugged into router). Alternatively, another workaround is disabling the upper CPU frequencies and living with a slower router (not ideal at all). And you might not even have the issue given different CPU bins from Qualcomm; this could be specific to this router. I have a second NBG6817 but it's at a different house where I don't have the time to test with it.
rejoicetreat has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Huh, okay - earlier I enabled the dynamic debug info for the cpufreq governor, and right before the hard reboot without the voltage boost, CPU 1 was actually transitioning to a lower frequency, not a higher one! CPU 0 remained at 1725000 during this time, so it might be when different cores are at different target frequencies. (Maybe I need to slightly raise the voltage across the board?)
<digitalcircuit>
[ 1400.590562] cpufreq: notification 0 of frequency transition to 800000 kHz
<digitalcircuit>
...then reboot. Unfortunately, there's no messages about L2 cache frequency, and I didn't notice any in the dynamic debug options. Might be a different setting.