SpectreDev_01 has quit [Quit: Connection closed for inactivity]
autkin has joined #openwrt-devel
f23xhxxx has quit [Ping timeout: 480 seconds]
f23xhxxx has joined #openwrt-devel
autkin has left #openwrt-devel [#openwrt-devel]
autkin has joined #openwrt-devel
vincejv has quit [Ping timeout: 480 seconds]
<f23xhxxx>
I quite do not get it, why official openwrt build config for wrt1900ac has enabled all firmware for ath broadcom and what not, that supposed to be some sort of starting point?
<f23xhxxx>
What I am looking for is bare minimum for functioning router.
<f23xhxxx>
The math somehow does not add up, when I donwload prebuilt image it is 8.3M big, I really doubt that image built with the official build config will result in such a small size.
<slh>
on average the default images including luci are roughly in the 7.5-8 MB range, those are feature complete and 'working'
<slh>
there certainly is some optimization potential when it comes to downloading bcm43xx firmwares and similar, semi-generic tools. but those are only (not-) used in the cross-build environment, not the resulting image
<f23xhxxx>
Where I can get config that is used to produce the official bin images?
<f23xhxxx>
Are you sure that this config is used to produce official bin images? They definitely will not be smaller than 40M
<slh>
yes
<f23xhxxx>
I need this config ->on average the default images including luci are roughly in the 7.5-8 MB range, those are feature complete and 'working'<
cmonroe has joined #openwrt-devel
<f23xhxxx>
If I will use buildinfo config from repo my image will be ~40M
<f23xhxxx>
In other words buildinfo config from link you posted is not the same config used to produce 7.5-8M image
<slh>
(disclaimer: don't own any mvebu devices myself)
<slh>
but that's everything you /need/ for a basic image, ~roughly similar to the release ones (but not building all the stuff you don't need)#
<f23xhxxx>
That is exactly what I am looking for
<slh>
save as .config, "make -j$(($(nproc) + 1)) defconfig oldconfig download world" and off to the races you go
<f23xhxxx>
thanks @slh
<f23xhxxx>
Just one last question is that v2 and multiprofile option really needed there?
autkin has left #openwrt-devel [Error from remote client]
<f23xhxxx>
chips from v1 and v2 differ, eg v1 chips are not present on v2 and vice versa
<slh>
no, but - you didn't specify if you had v1 or v2, so I just added both to the config (doesn't add much build time) - and I usually build for multiple devices from the same target, so I always add CONFIG_TARGET_MULTI_PROFILE=y and CONFIG_TARGET_PER_DEVICE_ROOTFS=y - it doesn't hurt, but helps a lot if you do need slightly adapted images for multiple device of the same target (and yes, add
<slh>
CONFIG_TARGET_PER_DEVICE_ROOTFS=y to the example config above)
<slh>
if you only have the v1, just omit the v2 (but I'd keep CONFIG_TARGET_MULTI_PROFILE=y and CONFIG_TARGET_PER_DEVICE_ROOTFS=y, doesn't mean you need to, but it just keeps things neat if you do want to extend that later)
<f23xhxxx>
oh my bad )
<f23xhxxx>
tnx for tip @slh
<slh>
the shipped config.buildinfo is correct and exactly what's been used to build the provided image, but you can simply save yourself a heap of build time and storage space for the build process, if you reduce that to the things you really need/ want for your device
<f23xhxxx>
how risky is to use snapshot images?
<f23xhxxx>
on daily basis
<slh>
I always use snapshots, there are rather rarely any issues with that, but chances are non-zero - on the other hand, those linksys mvebu devices are trivial to recover, so little risk
<slh>
it's a matter of preferences and how comfortable you are in the rare cases you do encounter issues
<f23xhxxx>
Well, for 4 years I ran fbsd current on my desktop, only few times run in to serious issue, so great to know
<slh>
and how often you do want to upgrade
<f23xhxxx>
I do not mind daily
<f23xhxxx>
build reflash reboot not that much a hassle
<slh>
following the main branch, something between two and eight week cadence is sensible
<slh>
I do follow the git history to spot the things that are of interest to me (or which might fix stuff I use)
<slh>
daily is a bit excessive, not that much changing on a daily basis to be worth it - weekly perhaps
<slh>
but, again, personal preference
<f23xhxxx>
main is the same as head?
<slh>
yes, it's the development branch, from which the snapshots are built
<f23xhxxx>
how difficult would be to use RSBAC with openwrt?
<f23xhxxx>
instead of SELinux
<slh>
rather advanced
<slh>
anything that needs additional out-of-tree kernel patches is not going to be fun, at all
<slh>
keep in mind that OpenWrt needs multiple layers of patch series to add basic SOC support, these are embedded devices after all
<slh>
rebasing an invasive non-mainline patch set on top of that, 1-2 times a week - plus additional config symbols, packages, etc. not. fun. at. all.
<slh>
push for it to get mainline, then it's going to be reasonable, until then... you'd have to be quite a masochist to even try
<f23xhxxx>
ok, this one at a later time
<slh>
even for an x86_64 target build that would be painful, but non-x86, ...
<slh>
I know (well, google and wikipedia told me), but it would be extremely 'not fun'
<f23xhxxx>
ok I see
<slh>
you have a very invasive external patchsetm you'd have to massage into the rather big patch sets (multiple layers) OpenWrt needs
<f23xhxxx>
By all measures it is far better option
<slh>
plus kernel- and userspace packaging changes and constant rebasing
<slh>
'possible', but very much on the hard side
<f23xhxxx>
What is the smallest board supported by openwrt?
<slh>
8 MB flash, 64 MB RAm right now, but that's going to become 16/128 with the next release
<f23xhxxx>
Board with lesser number of components
<slh>
mt7628 perhaps (but I wouldn't even look at those)
<f23xhxxx>
You mean release 24?
<slh>
yes
<f23xhxxx>
ok
<slh>
wpa3 needs an ssl provider, and that pushes 8 MB flash devices quite to the limit
<slh>
~600 KB for mbedtls, ~900 KB for wolfssl, ~1.5 MB for openssl, which is a lot for 7.5 MB available flash - and everything else is constantly getting larger as well
<f23xhxxx>
Is those components written in C?
<slh>
mt7628 as a SOC is highly integrated (so few external components, if you don't need 5 GHz support), but quite dated by now - slow and 'special' (not at all comparable to the level of support and ease of e.g. mt7621). it exists, but don't buy that stuff (mt7628) in 2024
goliath has quit [Quit: SIGSEGV]
<slh>
yes
swalker has quit [Ping timeout: 480 seconds]
<f23xhxxx>
I think one of the problems is the tool, it is not wise today use gcc llvm for embedded stuff it is just plain dumb
<slh>
mt7621, mt7622, filogic 820/ 830 (880)m ipq40xx, ipq806x, ipq807x are more typical targets that make fun these days
<f23xhxxx>
there is tcc pcc v scc that could be used
<slh>
you don't want to maintain different compilers for two dozens of platforms
<slh>
heck, even rust is painful (mips)
<f23xhxxx>
of course, but look at scale 50gb vs 2mb
<slh>
doesn't matter, at all
<f23xhxxx>
sloc
<f23xhxxx>
2mb is far more maintainable than 50G
<slh>
on the one hand gcc doesn't need 50 GB - on the other hand, dealing with 650 GB once for everything would still be better with half a dozen of snow-flake compilers, that doesn't scale over -many- targets, some of which with a quite peculiar toolchain status
<f23xhxxx>
even 2mb x 200
<f23xhxxx>
Why would you think that one compiler should be used for everything? It is not wise either
<slh>
manpower and time in the day is limited, severely limited and build resources are everything but free as well
<f23xhxxx>
again, for 50G you will never have enough manpower
<slh>
it's all fine and dandy if you can compile hello_world.c into less than 1 KB with pcc, but that's totally irrelevant if you need gcc for kernel, musl libc, busybox, hostapd, mbedtls anyways
swalker has joined #openwrt-devel
<f23xhxxx>
compilers grow faster that people are produced
<slh>
micro-optimizations typically come with a huge maintenance cost+
<f23xhxxx>
use chatgpt
<slh>
no.
<f23xhxxx>
ok what is micro-optimisation?
<f23xhxxx>
I can tell you why things are that whay
<slh>
as in building binary a with compiler 1, because the resulting binary is x% smaller, while you need compiler 2 for binary b, because it wouldn't build on 1 - and for e.g. bcm47xx you'd need compiler 3, because 1 and two don't have toolchain support for mips32
<f23xhxxx>
You won't have new people comming in to the scene because noone has a computer that can handle LLVM, GCC, MSVC. The barrier of entry is not only high but is becomming expensive
<slh>
if your build host isn't capable to run gcc, you need to get a better computer
<f23xhxxx>
How much money you make as an open source developer?
<f23xhxxx>
per month?
<slh>
that is irrelevant
<f23xhxxx>
"if your build host isn't capable to run gcc, you need to get a better computer" that's not even argument
<slh>
it is
<f23xhxxx>
That is very relvant, don't tell me that there is manpower shortage
tSYS has quit [Quit: *squeak*]
<slh>
there is, always - hardware is 'cheap' in comparison
<f23xhxxx>
give me example
tSYS has joined #openwrt-devel
<f23xhxxx>
from wallamrt amazon etc
<f23xhxxx>
^amrt^mart
<slh>
I am occassionaly building OpenWrt on an Athlon 64 X2 4600+ with 4 GB and on 250 GB spinning rust - that isn't particularly funny, but possible (and yes, you can older, I just try to avoid it for heavy compiling), that is 2006-era hardware
<Namidairo>
surprised all of ipq50xx has more or less stayed untouched although I imagine it might actually just be 807x with even more memory constraint issues
<slh>
Namidairo: ipq60xx is still facing quite some work - and in comparison to ipq50xx, ipq60xx often has more RAM. in the end ath11k is memory hungry and 512 MB are the bare minimum for it, so any devices with less than that will be... difficult
<slh>
ipqipq53xx will be more interesting (not to talk about ipq95xx)
f23xhxxx has quit [Ping timeout: 480 seconds]
<slh>
but, yes, with enough RAM, ipq50xx should be possible - if there are tempting devices
f23xhxxx has joined #openwrt-devel
tidalf has joined #openwrt-devel
f23xhxxx has quit [Remote host closed the connection]
<nbd>
nomad03: i think the easiest approach to fix netifd would be to change proto-shell.c to turn state->proto_task into an array with 2 entries (and fix all places that use it)
<nbd>
and then change proto_shell_notify and its ubus message enum to accept an index
<nomad03>
ugh, patching netifd... seems like it'll take long time to get aproval
<f00b4r0>
nbd: been investigating a return of the bug that was "handled" here: https://dev.archive.openwrt.org/ticket/17839. I've tested re-adding the local_irq_disable() bit to the restart handler, adding a readl() to try extra flushing, and even the for(;;); that was touted as working but none of that works (the latter bricks the device during boot, suggesting the reset is asserted during boot, which seems odd)
<f00b4r0>
I'm running out of ideas though. Especially since the bug only affects one variant of devices with Zentel RAM (devices with same board revision using Winbond RAM are unaffected)
<f00b4r0>
I dug the datasheet and the only difference I could spot was that Zentel does not support Off-Chip Driver impedance adjustment, and I fail to see how that could play a part in this bug