Slimey has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
javed2244 has joined #openwrt-devel
<javed2244>
Hi We are new to using OpenWRT not sure if this is the write place to post the query.If I am wrong about it requesting you to share me the proper mailing address to post the same query. We are trying to integrate a external test application (simple hellow world application) to openwrt.We are able to cross compile and move the exe to the openwrt running VMbox. Now our query is we want to modify our source code and generate a .so and how do we sha
<javed2244>
what chnages in make file would help this out. How do we integrate the .so to reflect the chnage in the box. As we want to give the customer to the .so file alone not exe everytime
svanheule has quit [Remote host closed the connection]
<Tusker>
you want to be able to distribute a shared library, to be used by an application? So, two opkg, one for the main executable, and one (or more) for the dependent libraries ?
<slh>
and SFP instead of SFP+ isn't quite convincing for a new model either (obviously the GX-412TC wouldn't be able to cope with 2.5 GBit/s or more in the first place, more of a reason for a modern device)
<fda>
@dangole : xt_dscp & xt_DSCP are available in openwrt! they are hidden in symbol "CONFIG_PACKAGE_kmod-ipt-ipopt" which means ip-options. So searching for "dscp" in menuconfig cant find anything as it does not search help text :) Maybe it is better to create a selectable submenu with old name an there are all modules listed and selected by default (to keep current behaviour)? This make it easier to find modules by search, atm the best source is
<fda>
netfilter.mk file
<fda>
have you an idea what i could try to fix the ubi-writing problem?
<fda>
i build SDK for all my devices, but it seems im to silly to use :) when i unpacked it and make, it seems all packages are built!
<fda>
additional dl/ dir should not be included in the sdk-tar - im using a link to keep dls and share between differen buld dirs
Tusker has quit [Remote host closed the connection]
<dangole>
fda: ?! writing to UBI is still a problem for you? I thought what we were dealing with was a combination of broken mtd-mac-address (due to recent patches, you may try to revert those) and cpufreq taking the CPU to 30MHz instead of 300MHz...
<dangole>
fda:
<dangole>
fda: the idea of the SDK is that you download it and use it to only build the specific packages you need to build from source, which allows you to use binaries for everything else
<dangole>
fda: building the SDK from source and then using that can also be useful: you will be able to build packages for a running device in the field even years after. but that's not what you are doing now.
<dangole>
fda: of course, if you like, you can just build everything from source. but it will be very hard for us to reproduce your problems if your build host, some kernel compile-time options, ... are modified.
nlowe has joined #openwrt-devel
Tapper has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
<stintel>
* opkg_conf_load: Could not create lock file /home/stijn/Development/OpenWrt/openwrt/build_dir/target-x86_64_musl/root.orig-x86//tmp/opkg.lock: No such file or directory.
<stintel>
anyone seen this before ?
aleksander has quit [Ping timeout: 480 seconds]
glbp has quit [Quit: leaving]
aleksander has joined #openwrt-devel
<rsalvaterra>
stintel: Nope, haven't done x86 builds in a while…
<fda>
dangole: yes, writing does not work., old image: 30mhz + non-ondemand worked. then flash with 300mhz + ondemand could load previous settings, but change something + then reboot and device was not pingable. i've set set lan-mac manually, all other where manually yet before
<stintel>
rsalvaterra: hah, I think I've seen that page before
<dangole>
fda: no, that only fixes _label_-mac address which is mostly a cosmetic feature. and CONFIG_NVMEM=y is already set on mt7622, so that's also not the problem.
<dangole>
fda: i would recommend you to just checkout the exact same commit you were using before when things were working for you on the non-UBI build and use that with UBI. because non of these problems seem to be related to UBI, and if so, we would have to isolate the cause (as in: everything else should be exactly the same)
<rsalvaterra>
stintel: Last weekend I found a TG784n v3 and a HG8012H… in the bin, no less.
<dangole>
fda: it only gets applied later on boot, so the random mac may still flash up at some point during boot and that can confuse your switch.
<fda>
i've a running system with non-ondemand. when i sysupgrade there about 10ping lost until its flashed and rebooted. in this case there should yet be another mav be assigned
<fda>
but i could try to flash again and no saving but only reboot. maybe remove lan cable additional. should i?
<dangole>
fda: if you are not afraid of that, the first thing it'd do is attach serial console. because then you actually see what's happening and not sit in the dark any more.
<fda>
the screws are under a label. if i remove it, i can not return anymore, just in case... its 1-2 weeks old
<fda>
but when i do something it can no loger be flashed i'll atach a console
<dangole>
fda: you have replaced the bootloader. you cannot return it anyway (and shouldn't, because it will encourage vendors to lock down even more if the see RMA piling up with replaced bootloaders).
<fda>
sure, return only with stock firmware
<dangole>
fda: if all your worries are for cosmetics: heat up the label a bit with hair-dryer and use a razor blade to remove it :)
<fda>
so i want brick or open it yet :)
<fda>
@dangole ive send you a link with used patches. none should harm, except the ondeman
<fda>
if 1200_dts is needed is not sure, ive not yet tested without
<fda>
but its not related to this device
<dangole>
fda: can you send me diffconfig and exact commit level as well?
<dangole>
fda: and did you make any changes using kernel_menuconfig?
<fda>
im deleting whole clone and cloning and then apply in the root
<fda>
for x in *.txt; do patch -p0 < $x; done
<fda>
except unused
<dangole>
fda: the patches all look innocent.
<fda>
yep
<dangole>
fda: more worried about changes in menuconfig (other than just adding/remove packages) or kernel_menuconfig
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fda>
dangole: iv added __create_config.txt
nlowe has joined #openwrt-devel
<fda>
dangole: ive updated the file
<dangole>
fda: nothing which looks related. so i believe we can almost conclude that updated TF-A doesn't work with Linux doing cpufreq scaling. that's not terribly surprising to me, as typically, cpufreq and cpuidle are features to be implemented at least partially in TF-A...
<fda>
with non-ubi it worked 1 week for me!
<fda>
@dangole maybe i should build an image with ubuntu. what distro are you using?
<fda>
with freetz i had a lot problems because fedora (and selinux)
<dangole>
fda: as i said, the UBI installer not only changes the flash layout. it replaces U-Boot from 2014 with U-Boot 2021.04. It also replaces hacked-up old-school TF-A and proprietary preloader with modern TF-A 2.4
<fda>
"unset which" is also fedora-oyl related
<fda>
ah, okay
<dangole>
fda: and there is no implementation for cpuidle or cpufreq in TF-A 2.4 for MT7622, it's just missing (but you see it there for other targets)
<fda>
new plan: i buld a last ubi image with ubuntu, just to be sure. if it not works i revert back to non-ubi to be able ondemand
aleksander has quit [Read error: No route to host]
<fda>
5°C more is much
<dangole>
fda: or try to implement support for Linux to use CONFIG_ARM_PSCI_CPUIDLE in TF-A :)
<fda>
im not a c(pp) developer
<dangole>
fda: be aware that practically all power-management stuff is disabled in OpenWrt. I'd expect a lot of things to break when using cpufreq (that's why i didn't even try)
<fda>
what could break? I've nothing notice in 1st week
<fda>
it worled perfect! i wanted just to be nice to flash :)
<fda>
andi dont need more then 30mb, my currently image has 24mb
<dangole>
fda: a lot. this SoC is complex and there might be a lot of corner cases in which you rather shouldn't transition from one freq to another, or assumptions in code about clock freq not changing in random drivers, ...
<fda>
hm
<dangole>
fda: it's just something nobody ever tried
<fda>
i read about it in the forum :)
<dangole>
fda: but i'd also be interested to see if the problems you see actually go away if you go back to the vendor's preloader+uboot+atf and otherwise use an identical build
<fda>
the build is identical! i just changed in my script CONFIG_TARGET_mediatek_mt7622_DEVICE_linksys_e8450-ubi=y
<dangole>
fda: i'm using archlinux locally, but Ubuntu is used by github CI which creates to binaries you find on github.com
<fda>
same buld vm
<dangole>
fda: same commit level?
<dangole>
fda: or you just clone master and you get whatever you get?
<fda>
no, latest
decke has quit [Quit: Leaving.]
<fda>
i read what i get!
<fda>
ive a local gitweb which collect some gits
<dangole>
fda: so please lookup the commit level of your working build, checkout that and build exactly that with UBI instead of non-UBI. that will tell a lot more than testing a lot of unknown changes together.
<dangole>
fda: e.g. kernel was bumped from 5.10.49 to 5.10.51 just some days ago. small commit, LOTS OF CHANGES
<dangole>
fda: (potentially, i haven't checked)
<fda>
my last non-ubi was created 20.7.21
<dangole>
fda: that's a bunch of changes, and some related to uImage.FIT, a kernel version bump, ...
<dangole>
fda: maybe I broke the FIT parser when making it work on MBR-partitioned eMMC (mt7623), could be :) I'll test that a bit my E8450 now...
<fda>
i build on ubuntu, maybe 1 hout as it has no ccache
<dangole>
fda: with or without cpufreq?
<dangole>
fda: because i think you should try without, evaluate, then switch that on, because then we would have isolated that being the cause
<fda>
ive running an image without ondemand
<fda>
built with fedora. works great, reboots fast
<fda>
saving is possible
<fda>
no problems
<rsalvaterra>
dangole: And even if things don't break, cpu{idle,freq} could introduce jitter. Theoretically, of course. I haven't noticed any issues on my MT7621 (with cpuidle enabled).
<dangole>
rsalvaterra: if possible, cpuidle would be the way to do. cpufreq feels like late-90s to me :)
<rsalvaterra>
dangole: Indeed, CPUs are getting smarter (moving PM to hardware as much as possible).
Rentong has quit [Remote host closed the connection]
* rsalvaterra
still has a couple of laptops requiring k8-powernow, though…
<dangole>
fda: but now, again, you are going to change 15 variables at once which will make it hard to isolate the cause of the problem. who knows why the build you got now works...
<fda>
15 variables?
<fda>
autofix? the config is invalid
<fda>
run kconf and save and you get the same result
<fda>
these symbols are not allowed to be selected because of some depends which are not selected
<fda>
maybe openwrt runs defconfig or something during build
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<fda>
dangole: and even GF128MUL is be selected by something else
Rentong has joined #openwrt-devel
<dangole>
fda: not talking about configuration variables, but variables in reality which you are trying to evaluate all at once
<fda>
? i dont understand
<fda>
in which file?
<fda>
the EOX part?
<dangole>
fda: you are changing buildhost, changing git commit level, ... maybe just do it one step at a time
<dangole>
fda: at this point i'
<dangole>
m also not expecting big surprises when building this on ubuntu...
<fda>
im currently running r17174-f7ab41acc9
<fda>
the later commits are not related as they are other devices
<fda>
and r17174-f7ab41acc9 is only cosmetci, as you said
<fda>
but i could also use f7ab41acc9
<dangole>
fda: and on the new buildhost, first build with default config, see if that works, then diverge one by one
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fda>
okay, without the autofx sound good.
<dangole>
fda: and for the fun of it, i'll also create a build with all your changes on my host, especially also cpufreq enabled (as i got serial and jtag connected, so i see more)
<fda>
but in case some symbols are mandatory, should they be selected my openwrt-config? the next one opens kernel-kconfig will delete them too
nlowe has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<dangole>
fda: in theory you are absolutely right, but it's yet another theory......
<fda>
:D
<dangole>
ynezz: mac addresses in current snapshot (b3092487) on mt7622 are still broken for the E8450 (spi-nand). nvmem seems to read from the wrong place in flash or something like that...
<dangole>
yenzz: a no, it's not the wrong place in flash but rather entirely random
rejoicetreat has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
nlowe has quit [Read error: Connection reset by peer]
<ynezz>
dangole: can you please post that info to PR#4041?
<ynezz>
is it actually reading the MAC from that spi-nand or it's random?
<ynezz>
is there any error visible in dmesg related to the nvmem?
<dangole>
ynezz: it's completely random on every reboot.
<dangole>
ynezz: [ 0.771140] mtk_soc_eth 1b100000.ethernet: generated random MAC address ca:0d:df:c3:35:e5
<ynezz>
yeah, so it's not reading it from nvmem
<ynezz>
or the address read from the mtd is invalid
<rsalvaterra>
WTF of the day: "no __ex_table in file: vmlinux"
<rsalvaterra>
I wonder if it's binutils 2.37 related…
<dangole>
fda: i got some results. so: TF-A freezes on boot and never loads OpenWrt if the reboot happened with ondemand governor enabled. i reckon mtk should fix that in TF-A rather than us working-around it by clocking up CPU before reboot...
<dangole>
fda: this happens only if current frequency is 300MHz at the time of the reboot, no matter if it was set by ondemand, powersafe or userspace governor. if i set manually 475MHz, it works again. i reckon the 300MHz operating point should be reconsidered
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
<dangole>
fda: ok, i got ondemand working by just removing that lowest operating point with 300MHz @ 0.95V. 437.5MHz @ 1.00V works fine.
<dangole>
fda: and looks like TF-A is freezing in the (binary/non-open-source) memory calibration part, so not much we can do without help from someone in mtk...
<dangole>
fda: btw. when setting that faulty 30Mhz, in reality it became ~125MHz as apparently clocking registers don't allow to go any lower...
<dangole>
fda: didn't want to play with too much because that's how to destroy a cpu (messing around with freq and voltage)...
<rsalvaterra>
dangole: Messing around with frequency should be fine, you might get hangs, but that's all. Voltage, however…
<dangole>
rsalvaterra: and as the frequency in DTS was very obviously wrong and it's the only one defined to operate on 0.95V, i wasn't to eager to explore the possible impacts...
<rsalvaterra>
So, it works at 30 MHz, works at 300 MHz, but with DVFS it breaks if the frequency drops below 475 MHz…? Did I understand correctly? o_o
<rsalvaterra>
*437.5
aleksander has joined #openwrt-devel
<dangole>
rsalvaterra: no matter what you set, the lowest possible freq which can ever be set is 125Mhz. just no way to program the registers of that CPU for it to be less.
<dangole>
rsalvaterra: in DTS, the is an operating point defined for 30Mhz, which seems wrong thus.
<rsalvaterra>
Yeah, obvious typo.
<dangole>
rsalvaterra: assumed that it should be 300Mhz instead...
fda has joined #openwrt-devel
<dangole>
rsalvaterra: however, no matter if it's 125Mhz (which it ends up to be if you set 30Mhz) or 300Mhz, if it operates on that frequency during reboot, DDR calibration hangs and it never boots.
<dangole>
rsalvaterra: and that's what happens when setting ondemand or powersafe governor, as it's the lower available operating point
<rsalvaterra>
There are exceptions, but usually there's a lower limit for how low you can clock a CPU, since there's dynamic internal state which gets lost in such conditions. :)
<fda>
dangole: i made some teste
<fda>
and have no backlog!
<fda>
it seems all images worked, even these before
<fda>
but not by "reboot", i have to power off + power on!
<dangole>
rsalvaterra: simply not using that OPP (ie. deleting it from DTS) and hence falling on 437.5Mhz then being the lowest solves it
<dangole>
fda: that matches my observation. try deleting that 30Mhz aka. 300Mhz OPP from DTS, so that 437.5Mhz is used as lowest and see if it fixes reboot for you
<rsalvaterra>
I'm going to ask a stupid question now… what does the OEM firmware do?
<rsalvaterra>
I wager it runs at a static frequency…
<fda>
is there some "prima test" package in openwrt? maybe i should run it before reboot? :D
<fda>
prime
<fda>
i had also lan unplugged during reboot (because of macs), did not help
<fda>
another pbservation: an image which hangs after "reboot" command, could be flashed with the same image again - and the startup works
<fda>
dangole: (flash by luci)
<dangole>
fda: for me reboot hangs reliably when CPU is @300Mhz, completely independent of what I did or did not do to the flash just before (i use userspace governor and set the freq manually to make deterministic results)
fda has quit []
<dangole>
rsalvaterra: stock firmware runs the CPU at max freq, no matter what. doesn't even have cpufreq built into the kernel.
<rsalvaterra>
dangole: Yeah, I suspected that much… lazy manufacturers… :)
<dangole>
rsalvaterra: the giant heatsink should allow for that, but ~5 degC more (reported by @fda) is also not so little energy just burned for nothing
fda has joined #openwrt-devel
<rsalvaterra>
dangole: I'd love to enable cpu{idle,freq} on my Omnia too, but alas… buggy hardware, hangs on high loads. :/
minimal has joined #openwrt-devel
fda has quit []
fda has joined #openwrt-devel
danitool has joined #openwrt-devel
<rsalvaterra>
Rats. Binutils 2.37 seems to break the kernel compilation on ARM/Cortex-A9, at least.
minimal has quit []
minimal has joined #openwrt-devel
<fda>
dangole: how you noticed the devices does not boot @300mhz? i thought it worked for you, but lan needs a log time maybe because of mac?
<dangole>
fda: i thought the hang on boot was related to the slightly shitty PoE-splitter i use to power the device, swapped power supply and then it went ok. and i see what's happening because i got serial port connected, so i saw it would boot all the way but still not be reachable, and that was because of randomized mac address.
<dangole>
fda: and you can try setting 300Mhz and reboot, it will always hang. echo 300000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed ; reboot
<dangole>
fda: ie. this happens even with userspace governor and is not related to ondemand. you and also just set 'powersafe' governor, it will also lead to every single reboot not working
<dangole>
*you can also
<fda>
im ucrrently build without 300mhz
Tapper has quit [Read error: Connection reset by peer]
<dangole>
fda: that's what i did, now running on the E8450 serving all my wifi devices in the house with ondemand governor and rebooted couple of times to try => no problem
<fda>
what about : echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq && reboot ? :D
minimal has quit []
minimal has joined #openwrt-devel
<fda>
after that cpuinfo_min_freq=437500 cpuinfo_cur_freq=600000
<dangole>
fda: with 437.5Mhz or 600Mhz reboot works without problems and yes, that's exactly how i tried
<dangole>
i didn't try other freqs, probably worth evaluating all of them to be reboot-safe :/
<fda>
i could replace the busybox link by a script which sets the freqency and the runs the applet ^^
<fda>
maybe its not the frequencey, but to less voltage?
<dangole>
(so now we already now that 125Mhz@0.9V and 300Mhz0.9V are not safe)
<dangole>
fda: yes, i thought that, because only that freq operates @0.9V
<fda>
why is 125 not safe? i never see i
<dangole>
the 30 Mhz typo ended up to be 125 Mhz in reality
Tapper has quit [Ping timeout: 480 seconds]
<dangole>
(because, apparently, that's as low as you can possibly go on that chip)
<fda>
125 worked for me great, with non-ubi!
<fda>
i then the bootloader does not properly resets volt/mhz
<fda>
i though
<fda>
and the old/vanially bootloader did it
<dangole>
with old TF-A you mean. it's not related to UBI, but to ancient MediaTek proprietary preloader in the stock layout vs. ARM Trusted Firmware A bl2 being used as (99.5% FLOSS) preloader
<dangole>
fda: yes, probably that's exactly what's happening. TF-A doesn't reset CPU freq and voltage early enough, tries to calibrate DDR RAM first and hangs there for ever then
<fda>
i dont know how to properly fix this. the best i can do is writing a sciript replacing reboot
<fda>
what could be the reason 125 mhz is missing?
Tapper has joined #openwrt-devel
<fda>
i read some people overcloked it to 2ghz @1,3v
Tapper has quit [Ping timeout: 480 seconds]
<dangole>
fda: that's the typo you already fixed in your patch?! and yes, that (30 Mhz) then becomes 125 Mhz because that's the lowest value you can program into clocking registers apparently
<fda>
30 was 0,95 volt. maybe we should try 125 @ 1.0, which is 437mhz in the dts?
<dangole>
fda: why 437 in dts? i think you misunderstood something
Tapper has joined #openwrt-devel
<dangole>
fda: 437.5 in DTS becomes 437.5 in reality, that's alright. just the 30 Mhz typo in DTS becomes 125Mhz in reality.
<fda>
dangole: i mean mor voltage for 125+300 which could maybe fix the reboot problem
<fda>
ah, there is not an additional step which was unused?
<dangole>
fda: you can try 300Mhz@1.0V or even 125Mhz@1.0V, and if both work, introduce 125MHz@1.0V as additional step (if the power draw is really lower with that setting)
<fda>
dangole: at least heat is less!
<fda>
less volt=less heat
<fda>
more or less ^^
<fda>
powerconsol rised from about 5w to 6w
<fda>
but there is addition another device at this place
<fda>
its for sure less then 50ct/month
Tapper has quit [Ping timeout: 480 seconds]
<mangix>
rsalvaterra: it's apparently a bug in silicon
<rsalvaterra>
mangix: Yeah, it's literally set in stone… :P
<fda>
dangole: ive added 125+300 @1.0 and both where visivle in cpuinfo_cur_freq. evne a reboot worked!
Tapper has joined #openwrt-devel
<fda>
but with less voltage less head. its then only a workaround for bootloader but, which does not resets properly
Tapper has quit [Ping timeout: 480 seconds]
<dangole>
fda: no, higher voltage can mean less current draw and less resistance, and hence less heat. really depends, you have to measure...
swalker has quit [Ping timeout: 480 seconds]
swalker has joined #openwrt-devel
Borromini has joined #openwrt-devel
Tapper has joined #openwrt-devel
isak has left #openwrt-devel [#openwrt-devel]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
swalker has quit [Ping timeout: 480 seconds]
isak has joined #openwrt-devel
swalker has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Borromini has quit [Quit: leaving]
<fda>
dangole: i was eating, the device ran 35% @125 and 55% @300 - this is 1week temperature, day 1-5 ondeman non-ubi, 6+7 ubi @1,3ghz https://ibb.co/kyN6vz2
<dangole>
fda: i just wrote to MTK devs explaining our findings, pm your email and i send you a copy of the mail
<fda>
they should best know at which freuqencies it should run with which voltage
<fda>
if power consum is 0,5w more or less, i dont care. but mast cpus clock down, maybe at 80°C. And i have my internet acces upstais to have good lte reception
<dangole>
fda: exactly. and yes, the drop of temperature when using cpufreq and the device is more or less idle is significant, i can tell with my bare hand that it's lower.
<fda>
i have to say from 20-21 h was a "clothes dryer" on, on which ste device stands!
<dangole>
fda: recent discussion on linux-mediatek mailing list also revealed that thermal throttling apparently kicks in too early and could be setup to slightly more courageous values...
<fda>
same problem with raspberry4! it throttles at 80 if i remember correctly. in default case cpu has at idle 65!
<fda>
so i replace the case by a full passive block