freistil90 has quit [Remote host closed the connection]
Borromini has joined #openwrt-devel
minimal has joined #openwrt-devel
freistil90 has joined #openwrt-devel
freistil90 has quit []
<damex>
talking about rtl838x switches - does one really need to solder a 1mm resistor to 0.1~mm traces to enable serial for further serial access?
dangole has joined #openwrt-devel
goliath has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<damex>
https://github.com/openwrt/openwrt/pull/10486 this goes against openwrt rules i have held against before. NO ONE tested it but person who reported it. docs are incomplete and seem to be copy pasted from other similar switch. also no pinout of gpio to use.
<damex>
i am mad about this. got switch. found out that yes, i might really need 50ohm 1mm resistors in place , gpio pinout is unknown and i need to probe it
<damex>
s/gpio/uart/
<damex>
i did solder as described and trying to probe. really.
<Znevna>
ok
<Borromini>
damex: i think the committer is on the forums as well. I'm forgetting whether he hangs on IRC
<Borromini>
ah yes he does, same handle btw.
<Borromini>
he hacked quite a bit on the Realtek targets from what I know.
<aiyion>
robimarko, hauke: Just confirmed, the NanoPi does not provide the nvmem sysfs interface, if the defualt instead of the release config is used.
<robimarko>
aiyion: Then CONFIG_NVMEM_SYSFS should be enabled in the sunxi target config
<robimarko>
And not just for A53
<robimarko>
Borromini: He is usually on the IRC, with the same name
<Borromini>
yeah
danitool has quit [Read error: Connection reset by peer]
<f00b4r0>
that's one hacky way to "install". Very cute.
<f00b4r0>
i'm not convinced we should be building by default images for devices that require that level of hardware hackery to install to, but I guess that's another debate :)
<robimarko>
Why not?
<robimarko>
The end user choses whether they want to do it or not
<f00b4r0>
because anyone who have the skill to follow this install procedure certainly has the skills to build their own image.
<f00b4r0>
conversely, we don't send the signal to unknowing end users that the device is easy to install by having the image ready to download (an assumption a lot of people make)
<robimarko>
Well, people make assumptions about everything, that doesnt make them right
<f00b4r0>
last but not least, we ease the load on our limited infra
<robimarko>
That impact is minimal
<robimarko>
Cause, all you are doing is not packaging rootfs
<f00b4r0>
i'm not just talking about the buildbots though.
<robimarko>
I would argue that obscure targets that nobody uses are causing way more of a load
<f00b4r0>
and yes it's minimal, but minimal + minimal + ... adds up eventually.
<f00b4r0>
i would agree with that too. It's not mutually exclusive :)
<robimarko>
I am of an opinion that we should make reference images like we do now
<robimarko>
Unless the devices are unsuportable or there is a breaking bug
<f00b4r0>
I don't agree with that. Although it would make me happy: we can then start buildbotting qoriq images :)
<robimarko>
Wait, qoriq is source-only?
<f00b4r0>
it is
<robimarko>
Why?
<f00b4r0>
probably because it's a single device and 3 people using it? :)
<aiyion>
robimarko: in `config-5.10` and `config-5.15`? Or are those files generated from somewhere else?
<robimarko>
f00b4r0: Well, I am of opinion if it works and there are users build it
<f00b4r0>
that would add an extra hour build on phase1 and something like another 6-12 on phase2, AIUI.
<f00b4r0>
which frankly makes no sense at this stage.
<robimarko>
aiyion: You should use make kernel_menuconfig CONFIG_TARGET=target
<aiyion>
Seems like it. Will provide a patch soo.
<robimarko>
To select the symbol
<robimarko>
And remove it from A53 config
<aiyion>
saw that thanks
<robimarko>
f00b4r0: Why not at least build release images?
<robimarko>
That is what most of the users are using
<f00b4r0>
because it needs the accompanying arch build
<f00b4r0>
it's a separate arch, not just a separate target
<robimarko>
I understand
<f00b4r0>
and so for the sake of the 3 of us using the M300, I don't really think it makes sense to further load our infra. This is where I understand we disagree :)
<robimarko>
I like disagreeing
<f00b4r0>
it's ok. I like agreeing on disagreeing :D
<robimarko>
Would be weird if we all agree
<robimarko>
BTW, what the hell is archs38 target?
_lore_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<hauke>
robimarko: it is ARC HS38 CPUs ;-)
<robimarko>
I get that, but what boards are supported?
<hauke>
some evaluation platforms from synopsys
<robimarko>
Are those CPU-s ones that require special toolchain?
<hauke>
musl does not support ARC
<hauke>
The quantenna devices also used ARC CPUs
_lore_ has joined #openwrt-devel
<hauke>
but the quantenna SoCs are not supported by upstream OpenWrt
<robimarko>
That target sounds like an ideal candidate to stop building for
<robimarko>
Cause, its only touched to bump the kernel
<robimarko>
And usually once its in the few ones that are left to be able to branch for release
<hauke>
I think no hacker has such devices
<robimarko>
That is my logic as well
<hauke>
it looks like synopsys is ot so much inteetsed in these boards any more
<hauke>
s/ot/not/
<robimarko>
ARC in general looks to be not so hot stuff anymore
<hauke>
I do not think that anyone would still choose a ARC CPU for a new SoC design
<hauke>
ARM or RISC-V looks much more mature
<f00b4r0>
*nod*
<f00b4r0>
robimarko: looks like you should send a patch :)
<robimarko>
Looks like it
<robimarko>
Do we have download statistics for prebuilt images?
<f00b4r0>
i think there are some figures available but I don't know how relevant they are. Don't remember the url, I suspect aparcar would know
<robimarko>
Nicely linked on the infrastructure page
<f00b4r0>
heh :)
danitool has joined #openwrt-devel
<robimarko>
Whopping 19 views for archs38 in December
<robimarko>
14 image downloads as well
<f00b4r0>
lol
<f00b4r0>
probably all bots
<robimarko>
Yeah, I have the patch to make it source-only ready, just wanted to make sure no end users are using it
<hauke>
It is nice to have a target building with glibc
<f00b4r0>
if anyone is, they will complain anyway. No much harm in patching master
<f00b4r0>
hauke: is it the only one?
<hauke>
I do not think anyone is uisng the prebuild archs38 images
<robimarko>
hauke: It would be probably more beneficial to build glibc version of x86 instead
<hauke>
yes
<f00b4r0>
indeed
<hauke>
will probably get more productive users than archs38
<f00b4r0>
hehe
<f00b4r0>
somehow I thought x86 was already glibc. Must have been confused
<Habbie>
glibc? in my openwrt? is this a transition, or will there be choice?
<robimarko>
glibc was always an option
<f00b4r0>
would be separate I assume
<hauke>
there is already a choise since many years
soxrok2212 has quit [Read error: Connection reset by peer]
<f00b4r0>
yeah, just not the default one
soxrok2212 has joined #openwrt-devel
<hauke>
glibc supports the gcc sanitizers
<Habbie>
robimarko, oh right
<robimarko>
Anyway, sent the patch for archs38 source-only on the mailing list
<f00b4r0>
👍
soxrok2212 has quit [Ping timeout: 480 seconds]
tlj_ has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
shibboleth has quit [Quit: shibboleth]
<aiyion>
robimarko: I'm new to `make kernel_menuconfig`. `CONFIG=target` allowed me to set the value for /target/linux/sunxi/config-5.10 is there a list of valid targets i can use?
<aiyion>
I'm looking for a way to set 5.15, while I'm at it.
soxrok2212 has joined #openwrt-devel
<aiyion>
Is it expected that other values got set and removed as well?
<Borromini>
aiyion: anything in $target/$subtarget AFAIK
<aiyion>
Borromini: apparently I can use "subtarget" instead of "target".
<Borromini>
:)
<aiyion>
I chose a cortex53 device in regular menuconfig and it worked so far.
<Borromini>
what stuff are you porting?
<aiyion>
Problem is, I can not deselect it there.
<aiyion>
I'm trying to disable nvmem sysfs for cortexa53, because I'm enabling it for sunxi.
<aiyion>
The NanoPi R1 does not have a proper mac address store. Uboot gets that solved by using the secure ID of the SoC which is available for all h2+/h3/h5 devices.
<aiyion>
I got it working by using the cid of the mmc, but their approach is cleaner, so I'd like to fix it in OpenWrt to match theirs.
<aiyion>
Borromini: "CONFIG_TARGET=sunxi/cortexa53 is invalid. Valid: target|subtarget|subtarget_target|env. Stop."
<aiyion>
that settles it, I suppose.
<aiyion>
I don't get it. Clean repo, entering make kernel_config, chose target, subtarget, device, nothing else. set "target" as CONFIG_TARGET. hit save without changing anything else, still changes in the diff.
<robimarko>
You can just manually remove the line from a53 config-5.15
<robimarko>
Its should probably get removed anyway
<robimarko>
If you enabled it in sunxi target in general
<aiyion>
will do, thanks. Sorry for the tiny steps. It does not get removed after i add it in sunxi.
<robimarko>
Thats weird
<robimarko>
Try manually removing it, it shouldnt get readded
<aiyion>
will do, one sec.
shibboleth has quit [Quit: shibboleth]
<aiyion>
ffs. its 5.10 not 5.15
<aiyion>
cortexa53 5.15 contains the nvmem_sysfs entry one sees on github. but a53 generates 5.10 files, which do not contain the setting.
<aiyion>
Do I care about 5.15 files for the Patchseries?
<aiyion>
I could remove the line by hand, it (obviously) does not get added back in, or I leave it be.
<aiyion>
robimarko: ^
<robimarko>
Yeah
<aiyion>
sry.
<robimarko>
If 5.15 is supported, then same changes should be done to it
<aiyion>
Is there a parameter to call make kernel_config for other kernel versions but the current?
<robimarko>
You can select to use the testing kernel version via OpenWrt menuconfig
<robimarko>
I think its in global build options
<aiyion>
Nice to know, thanks will try.
Misanthropos has quit [Ping timeout: 480 seconds]
<aiyion>
was indeed in global build options, choses 5.15 now, thanks.
<aiyion>
I still cannot deselect it via menuconfig though.
<aiyion>
*kernel_menuconfig
<robimarko>
You cant as AT24 is selecting it
Borromini has quit [Quit: Lost terminal]
<aiyion>
So I jsut leave that alone? Or remove it manually?
<robimarko>
Remove it
<robimarko>
As it will be enabled in target config
Misanthropos has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
G10h4ck has joined #openwrt-devel
<G10h4ck>
Hi!
<G10h4ck>
nbd are you around? got some time to talk about AP-mesh hostapd modifications?
arifre has quit [Remote host closed the connection]
<aiyion>
My workflow must still be wrong -.-'
<aiyion>
depending on which subtarget I choose in make menuconfig, the diff resulting from `make kernel_menuconfig CONFIG_TARGET=target` contains more or less entries.
<aiyion>
I remove teh current .config and .config.old for a clean start.
<aiyion>
i run make menuconfig, choose the target and one of the three subtargets and run kernelconfig afterwords.
<aiyion>
urgh -.-' whoever reviews that patchset should get some Tschunks afterwords :/
G10h4ck has quit [Read error: No route to host]
G10h4ck_ has joined #openwrt-devel
G10h4ck_ has quit [Ping timeout: 480 seconds]
G10h4ck_ has joined #openwrt-devel
<aiyion>
alright thought I'd have it now, but this does not build anymore. `make -j1 V=s` halts on the question "ARMv4 based platforms (FA526) (ARCH_MULTI_V4) [N/y/?] (NEW)"
<aiyion>
this does not look right.
<aiyion>
Whatever I'm doing here. I've pushed the two commits here:
<aiyion>
"sunxi: update target and subtarget cortexa53" is the result of calling make menuconfig, choosing "Allwinner" and "Allwinner A64/H5" in menuconfig, saving and running the kernel_menuconfig command for both the stable and the testing kernel.
<aiyion>
"sunxi: enable CONFIG_NVMEM_SYSFS" is the commit with the changes I intended, as robert and hauke suggested.