<Mangix>
I find it funny that it's from a Google address
<PaulFertser>
In that particular case probably runtime patching (on kernel startup) the bootloader supplied DT is a sensible way.
<ynezz>
PaulFertser: good idea, is there such prior example?
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
maxmadzz has joined #openwrt-devel
<PaulFertser>
ynezz: yes, let me try to remember where I saw that.
<maxmadzz>
hi
<maxmadzz>
Why does the openwrt builder always find for GCC and LD commands instead of the command name specified in external toolchain?
<PaulFertser>
ynezz: so far I found just one example in bcm63xx/patches-*/411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch but I'm fairly sure there was some target in OpenWrt which was doing plenty of heavy DT patching on startup, just can't find it now.
<PaulFertser>
There're some examples in upstream Linux in arch/arm if you grep for of_add_property / of_update_property , there's even a special .dt_fixup field.
<ynezz>
PaulFertser: thanks, there seems to be similar apply_mips_fdt_fixups for mips
<ynezz>
in arch/mips/generic/init.c
<PaulFertser>
ynezz: indeed, searching for fdt_setprop is even more fruitful.
<hanetzer>
ahhhh. I think I got it. U-Boot not U-boot
<mrnuke>
Is the boot process doing some bumbleforgery to prevent kernel parameters such as "module.dyndbg=..." being passed down to the correct module?
<PaulFertser>
hanetzer: see include/u-boot.mk it has ifneq ($(BUILD_DEVICES),) DEFAULT := y if ($(TARGET_DEP)_Default
<PaulFertser>
hanetzer: so if you're building a single-profile image then you probably need to rm .config and regenerate it as DEFAULT package selection is processed just at the moment you select a profile.
<PaulFertser>
mrnuke: for certain targets the OpenWrt kernel ignores cmdline as passed by the bootloader and instead uses its own. You can check by cat /proc/cmdline.
rua has joined #openwrt-devel
<mrnuke>
PaulFertser: I see my flags in /proc/cmdline
<Mangix>
uhhh
<Mangix>
isn't qoriq build only? same with bmips
<Mangix>
hauke: step 2: configure glibc to do 64-bit time_t on every target, not just ARCV
<Mangix>
*ARC
<f00b4r0>
Mangix: you mean source only?
<Mangix>
yeah
<f00b4r0>
it is
SamantazFox has quit [Ping timeout: 480 seconds]
<Mangix>
rmilecki: I assume no wifi for Asus GT-AX6000
<rmilecki>
Mangix: yes, definitely
<rmilecki>
also a lot of DT stuff is missing
<rmilecki>
Mangix: we still need PCIe driver
<rmilecki>
for BCM4908 (BCM4912)
<Mangix>
oh wow
rua has quit [Ping timeout: 480 seconds]
raw-f0815 has joined #openwrt-devel
<raw-f0815>
Hi everyone, I have a question regarding the Aruba Devices
<raw-f0815>
Is it possible to build a firmware for the Aruba APIN0315
<hanetzer>
question, we still avoiding swig/BINMAN(in uboot)?
<Mangix>
hanetzer: nope
<hanetzer>
nice, that's a patch I can drop :)
<Mangix>
forgot the details. there was a PR where packages were added to CI
<hurricos>
hard "maybe", depends on how Aruba / HPE have done
<hurricos>
I know. Sometimes when folks come back it alerts them :(
Lynx- has joined #openwrt-devel
Lynx- has quit []
<Borromini>
hurricos: don't tell me you are still running 21.02 on all your stuff? I tend to switch to the new release branch as soon as it gets created :^)
<hurricos>
Borromini: I am running it on probably 40% of my stuff, mostly NASes and switches.
<hurricos>
Nothing like losing backups or access to the network because something chnanged :^)
<Borromini>
:P
<Borromini>
i still have to flesh out the VLANs & guest networks here before I deploy a similar setup to my brother's SOHO environment
<Mangix>
jow: ping
MaxSoniX has quit [Quit: Konversation terminated!]
Lynx- has joined #openwrt-devel
<Lynx->
is conntrack restore available on tc wan ingress
<Lynx->
(as in has the conntrack been applied before tc wan ingress sees packets?)
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<f00b4r0>
gee I have one set of seriously buggy netgear ex3700 APs. If I turn both radios on, they keep randomly rebooting :/
<hanetzer>
anyone running openwrt on any currently supported sunxi devices? bout to drop a pr to bump uboot-sunxi to 2022.01 and add a new device (which prompted the version bump)
<hanetzer>
I don't wanna brix anyone y'kno :)
<Habbie>
hanetzer, is there a list of what devices are sunxi?
<hanetzer>
Habbie: yeh, but that's not a user list ;)
<Habbie>
no, but i might find out i have one of these in a drawer somewhere (i don't)
<Habbie>
or somebody else might find out :)
<hanetzer>
I could pop into #linux-sunxi and have an ask :)
<Habbie>
makes sense - i suppose many of these boot from SD? people might be willing to test even if they don't currently run openwrt
<hanetzer>
yee
<jow>
Mangix: pong
<hanetzer>
pang
<Mangix>
jow: any objection to rewriting core openwrt tools build system to meson?
<jow>
what would that entail?
<jow>
what would we gain from it?
<jow>
whenever tools stuff gets rebuilt here it's cmake getting rebuilt over and over again
<jow>
if it does not introduce new prereqs and doesn ot require deviating from upstream then fine by me
<Mangix>
jow: relative to cmake, meson installs in less than a second. main benefit is that it makes development easier. meson wraps can handle missing dependencies. It automatically creates a .gitignore file to prevent "git add ." adding build directories. there are also smaller quality of life improvements.
<jow>
but we would still need cmake
<Mangix>
hmm>
<Mangix>
?
<jow>
unless the entire openwrt universe and any downstream user we don't know about converts its packages to meson we would still need to provide cmake as host util
<jow>
alos development? are we developing tools?
<Mangix>
I'm talking about core openwrt stuff such as libubox and ubus