<minimal>
there have been quite a few changes to entropy related code in recent kernels
<vulpes2[m]>
hauke: is the CI failure something I can fix? Despite the fact that it's running on ubuntu-latest I can't find any calls to apt nor a list of dependencies being installed in the container, so I'm not sure how to proceed at this point.
dansan has joined #openwrt-devel
<hauke>
vulpes2[m]: I do not think so, maybe aparcar[m] can help
<vulpes2[m]>
this setup is a lot more complicated than what I'm used to :p
<vulpes2[m]>
seems like the image at registry.gitlab.com/openwrt/buildbot/buildworker-3.4.1 simply needs to be updated
<mrkiko>
nbd: if I install llvm from Arch, may I select the "use host llvm toolchain" for the BPF toolchain option? May this lead to an unbootable system in case of failure, or just ebpf not working ?
<mrkiko>
nbd: btw, not using actively bpf on my own atm
<f0g>
Hi all. I found a password in a uci file, with value '$1$abc$Pes8mNPfq0xYVcUFx15rQ.' . I know that $1$ means crypt hash, but what means of 'abc' between the '$'?
<f0g>
Where can I find the document relate to this?
bluew has quit [Ping timeout: 480 seconds]
bbezak has joined #openwrt-devel
<damex>
f0g: salt
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
<nbd>
mrkiko: the llvm toolchain is only used for bpf stuff
<nbd>
mrkiko: it can't break anything else
<oliv3r[m]>
hauke: So cleaned everything, distclean etc; still, get: "Error: opcode not supported on this processor: mips32 (mips32) `ext $t5,$t4,0xF,0x1'" I don't even know where to start looking, as this was working fine days ago ...
SamantazFox_ has quit [Quit: Bye]
<ynezz>
oliv3r[m]: so you're using snapshot SDK container for which target and what are you trying to build? can you share some smallest reproducer?
<ynezz>
oliv3r[m]: which last version (Git hash) was working for you?
<oliv3r[m]>
ynezz: Yes, I'm using the openwrtorg:sdk container, which was pushed about 2 months ago. Since this assembly code is comming from a local patch, not yet in master, that's much harder to say. But I've built this branch many times in the past as well. https://gitlab.com/olliver/openwrt/openwrt/-/commit/b6cfe441bd5e2768c73df81f09ccebdb0b99b816 is the patch I have that triggers this behavior
<ynezz>
now I'm confused, it seems that you've copy&pasted some issue with meson/zstd
ptudor has quit [Ping timeout: 480 seconds]
<ynezz>
so what is not working exactly?
<oliv3r[m]>
that was yesterday, doing the distclean fixed that :) still no idea what caused that; but I pasted at 09:38 a mips32 error did I not?
ptudor has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<ynezz>
so which realtek container are you using exactly?
<oliv3r[m]>
openwrtorg:sdk
<oliv3r[m]>
the target i'm building for is rtl930x
<ynezz>
so openwrt/sdk:realtek-rtl930x-snapshot ?
<oliv3r[m]>
sure
<rmilecki>
hi, I can't build lighttpd locally:
<rmilecki>
Package lighttpd is missing dependencies for the following libraries:
<rmilecki>
libnettle.so.8
<rmilecki>
libpcre2-8.so.0
<rmilecki>
(but in snapshots I can see package from yesterday), any idea why?
<ynezz>
oliv3r[m]: ok, can you pastebin complete compile fail log?
srslypascal has quit [Read error: No route to host]
srslypascal has joined #openwrt-devel
<Mangix>
rmilecki: sounds like a race condition
<rmilecki>
Mangix: it happens with "make V=s" (no -j argument)
<Mangix>
right
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<nbd>
oliv3r[m]: not sure if it helps with understanding the issue, but it seems that the kernel is being built for generic mips32, and the "ext" opcode is mips32 r2 specific
<oliv3r[m]>
nbd: Sadly, generic mips32 is the next commit in the chain that I just break(broke?) before, so not applicable yet :( But CONFIG_MIPS32_R2 IS enabled!)
<rmilecki>
Mangix: so what race is that? any idea about possible fix?
<Mangix>
rmilecki: i meant if building with make -j 12 or whatever lightttpd gets built before libnettle
<ynezz>
Mangix: that just means wrong deps?
<Mangix>
wait a minute
<Mangix>
looking at the makefile, nettle is a configuration option
<Mangix>
and it should be disabled when unused
<Mangix>
post an issue on packages. gstrauss is active
<nbd>
oliv3r[m]: i have an idea:
<nbd>
right after .set noreorder, add this:
<nbd>
.set mips32r2
<oliv3r[m]>
ok i'll try; though why did it work just a few days ago :S
<nbd>
no idea
<oliv3r[m]>
nbd: hauke thought that my compiler wasn't able to compile this stuff, but again; it was fine just a few days ago, and 'all I did' was lots of compiling and rebasing :D
<oliv3r[m]>
i'm now building an old branch, that I know was working before
<ynezz>
building and building reproducibly are two different topics :)
<oliv3r[m]>
(I really need a new PC though; 12 years old :( though I think my CPU is only 8 years old :)
<oliv3r[m]>
ynezz: oh yes absolutly!
<ynezz>
BTW docker container updates are broken for ~2months so certainly not caused by some recent changes
<oliv3r[m]>
so what I do; I pull the sdk container, volume mount my devtree to /workdir (to not conflict with /home/build) and link in the 'staging_dir' from openwrt to my own dir
<oliv3r[m]>
but even forcing letting the container rebuilding staging makes no difference
<ynezz>
rmilecki: try to revert 43741e748f8569be4aaf3ba3a99867eef32c74e4
<ynezz>
"lighttpd: document crypto lib options in Makefile" since when "document" means completely rework build of the package? :)
robimarko has joined #openwrt-devel
<rmilecki>
ynezz: doesn't help
<rmilecki>
uh, I'll have to bisect I guess
<rmilecki>
or try more reverts
<rmilecki>
ddecac45c8f813b0711ec625ab424e33e7a8da9c ("lighttpd: update to lighttpd 1.4.62 release hash") says "depend on libpcre2 instead of libpcre" - worth checking too
<ynezz>
"Package lighttpd is missing dependencies for the following libraries: libpcre2-8.so.0" means, that it build fine, just the DEPENDS:= is wrong
<ynezz>
DEPENDS:=$(if $(CONFIG_LIGHTTPD_PCRE2),+libpcre2,) should perhaps be `DEPENDS:=+LIGHTTPD_PCRE2:libpcre2` ?
<vulpes2[m]>
hauke: I've noticed you've been migrating ATF packages to use trusted-firmware-a.mk, do you have similar plans for arm-trusted-firmware-rockchip as well?
<vulpes2[m]>
if nobody is working on it I could give it a shot
<mrkiko>
robimarko: ok, the AP1300 LTE works
<rmilecki>
ynezz: that seems to work!
<robimarko>
mrkiko: great to hear that
<rmilecki>
ynezz: let me double check that but I think it compiled fine this time
<oliv3r[m]>
robimarko: libdeflate support has been merged ;)
<robimarko>
Yeah, saw the notification
<rmilecki>
Mangix: ynezz: what a weird issue, after "rm -fr feeds/packages*" and reinstalling packages from feed I can't reproduce it
<rmilecki>
let me try another machine I saw it on
<oliv3r[m]>
ynezz: one thing that could trigger this, is I'm moving to a single configuration/build, where we support multiple targets. However, they are _all_ mips32r2
<oliv3r[m]>
Anyway, trying with your suggestion, hopefully that'll work
<mrkiko>
robimarko: is it expected that wan and lan have the same MAC?
<robimarko>
mrkiko: I dont have that device so no idea what glinet did
<robimarko>
But usually they are not the same
<robimarko>
oliv3r[m]: march is being set to mip32, not mips32r2
<oliv3r[m]>
robimarko: CONFIG_CPU_MIPS32_R2=y not good?
<robimarko>
oliv3r[m]: The kernel config you checked is .config from the kernel build directory or?
<oliv3r[m]>
yep absolutly
<robimarko>
Well, that kind of exhausts all of my ideas
<oliv3r[m]>
I know! me too :(
<mrkiko>
robimarko: ok, apart form that, all the rest seems fine
<Mangix>
now that the libdeflate stuff got merged, time to migrate everything to it :)
<oliv3r[m]>
what the ... why am I now all of a sudden getting this crap: ./arch/mips/include/asm/barrier.h:(.init.text+0x20): undefined reference to `__appended_dtb'
<oliv3r[m]>
where <asm/bootinfo.h> is still included. I'm so ready to just throw it all away and start again; which will take hours to compile shit :(
SlimeyX has quit [Read error: Connection reset by peer]
<oliv3r[m]>
and while I can fix it; and probably should; I don't understand why this is failing now all of a sudden, unless the LTS .85 changed things significantly ...
<robimarko>
Doubt that its kernel update
<robimarko>
As nothing has touched the arch makefile for over a year in MIPS
<aiyion>
Half an hour and I'm back with the Brume2... The darn thing still crashes mere seconds in the boot process...
<vulpes2[m]>
well, as long as swig is installed on the host
<mrkiko>
The GL-ap1300 has 4MB flash but partitions defined only for the first 2 MB more or less. Will there be really all zeroes after that?
<vulpes2[m]>
It's undefined, if you want to use them you should erase them first.
<mrkiko>
But I'm definitely too lazy to edit the DTS - wondering if there is a way to (re)-define an mtd partition on the fly
<mrkiko>
aiyion: issues with clock driver?
<mrkiko>
vulpes2[m]: was your message directed at me or not?
<vulpes2[m]>
yeah it was
<mrkiko>
vulpes2[m]: thanks! Did you already take a look? :D
<aiyion>
mrkiko: Not sure yet, I called it a day around christmas when compilation finally succeeded but booting failed. Will post the log when I'm home.
<mrkiko>
aiyion: mt7681 isn't as easy as one might think... really
<vulpes2[m]>
mrkiko nope, I don't have that device, but _theoretically_ they can come in any state (most likely all 0xFF tbh) if it's not erased all the way through in the factory
<vulpes2[m]>
I have a hunch that they would only erase the first 2MB if they are only going to use the first 2MB
xes_ has joined #openwrt-devel
<vulpes2[m]>
After all erasing NOR flash is still pretty slow
<mrkiko>
vulpes2[m]: thanks!! I think you're right in this case. But I was wondering since in the GL-MV1000 there was a copy of the stock firmware not added in DTS. I sent a patch as well, got no answer :D
<aiyion>
mrkiko: I'm afraid I won't learn much by avoiding not easy. The device does not have wifi, so that facilitates the proccess I hope
<aiyion>
afk for 15m
<vulpes2[m]>
but if you really want to use the "unused" space feel free to do so, since it's NOR and it's _technically_ free of bad blocks
<vulpes2[m]>
I remember some old atheros based Netgear stuff that had NAND with only the first half used, because the other half have more bad blocks than usual
<robimarko>
That is what UBI is for
<vulpes2[m]>
yeah I know
xes has quit [Ping timeout: 480 seconds]
<mrkiko>
aiyion: oh, I don't mean you should avoid not easy. Was just a tough
<mrkiko>
However, can someone look at a GL-AP1300 photograph? There is a thing near the sim slot - like an hole on the plastic but covered by another cover of plastic (my english is very bad). Is that for leds?
<robimarko>
There is reset hole and right to it is some weird plastic cover
<mrkiko>
robimarko: exactly...
<robimarko>
Its unmarked, looks like it could have been for another port
<robimarko>
Or maybe SFP
<robimarko>
I suppose they are reusing the molding
<vulpes2[m]>
it's just USB
<mrkiko>
robimarko: molding = the external plastic case
<mrkiko>
robimarko: ok, because this is LTE variant so probably the usb port underneath doesn't work as expected here
<vulpes2[m]>
(unused) usb
<robimarko>
So they seriously used that USB port for the LTE modem
<mrkiko>
thanks to all
<robimarko>
SoC has 2 USB ports, why not simply use the non-used one
<mrkiko>
robimarko: mhm, maybe not. But in various devices you can't use both the usb port and the internal LTE device. In this case the LTE device is a quectel EP06 so I don't think they "really" use that port
<mrkiko>
robimarko: mhm... who knows
<mrkiko>
but if they took the decision to cover it with a plastic thing, they really didn't want you to use that :D
<robimarko>
My point being, SoC 2 unique USB ports
<robimarko>
One being 3.0 and one 2.0
<mrkiko>
robimarko: I understand. Who knows... :D
<mrkiko>
robimarko: may it be because if they let you use both they would run out of power budget? I know LTE modems can use pretty much power if you're in the right conditions
<vulpes2[m]>
aparcar: would you mind taking a look at the container image used for CI test build workflows and possibly update it?
<vulpes2[m]>
Apologies about the double tagging if you got an email from the mention on github as well. Just want to make sure you're aware of this issue as I found most people have a lot of email notifications from github disabled. https://github.com/openwrt/openwrt/pull/11666
xes_ has quit [Ping timeout: 480 seconds]
xes has joined #openwrt-devel
<mrkiko>
aiyion: oh... it crashes suddenyl ... mhm...
<aiyion>
Gotta reopen the device, I think. Was pretty sure I read 86b not 81. But it was late. Maybe I messed up big time.
<aiyion>
thanks for the hint!
<mrkiko>
aiyion: and on the website they say it's mt7981B, so yes - chances are you need some patches from them. Or are different devices involved here?
<mrkiko>
aiyion: you're welcome :D
<robimarko>
They have the SDK patches from MTK in their Infra builder
<mrkiko>
robimarko: yess:D
esters has joined #openwrt-devel
<aiyion>
mrkiko: 81b. fml. thanks -.-'
<mrkiko>
aiyion: you're welcome :D
<mrkiko>
aiyion: so, I remember dangole having some "similar" issues when trying toport the MT3000, maybe he can help you out
<aiyion>
mrkiko: My issue is not beeing able to read properly. I really hope thats not dangoles ^^ But yeah, once I hit real problems, I'll have a look at his former patches
<mrkiko>
aiyion: sorry - what do you mean by "not being able to read properly" ? Serial console issues?
<aiyion>
soc ID.
<aiyion>
81 vs 86
<mrkiko>
aiyion: ah :D oh, don't worry. These things happen ...
<mrkiko>
aiyion: and, I would have preferred brume2 was 86 too :D
SlimeyX has joined #openwrt-devel
esters has left #openwrt-devel [#openwrt-devel]
ekathva has joined #openwrt-devel
<oliv3r[m]>
so weird, but now it compiled just fine again; I have no idea what's causing this bs :S make clean at least does not fix it
xdarklight has quit [Remote host closed the connection]
xdarklight has joined #openwrt-devel
floof58 is now known as Guest63
floof58 has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
Guest63 has quit [Ping timeout: 480 seconds]
<oliv3r[m]>
i've also done various rm -rfs' :p but that I hadn't tried yet
<oliv3r[m]>
distclean I did also :(
<oliv3r[m]>
I'm trying to migrate my platform to generic MIPS; with someone else's patch, I get zero console output. Fine, So I'll go deal with early_printk, no problem, I have a functional serial port. Are there any tricks to set that up? As I see everything is enabled in kconfig, but I bet I need to tell the kernel something about my serial port somewhere ...
<robimarko>
Just setting up the aliases corrently as well as stdout
<robimarko>
And adding earlycon to bootargs should be enough
<robimarko>
Hasnt musashino already done that?
<oliv3r[m]>
yes, but it's not working :)
<oliv3r[m]>
earlycon isn't in bootagrs though; so i'll need to add that
<oliv3r[m]>
ah wait it is
<oliv3r[m]>
but that's all devicetree magic; there surely is a much earlier way to output something on the serial port
<robimarko>
earlycon is not device tree specific
<oliv3r[m]>
setup_8250_early_printk_port(0xb8002000, 2, 0); used to be there
<robimarko>
You can try passing earlycon with the driver you want to use and address
<oliv3r[m]>
bootargs = "earlycon" is defined in the dt atm; i'll add that to my u-boot bootargs
<robimarko>
By passing earlycon=your driver and addr you avoid having to need a working DTB
<oliv3r[m]>
ah, that's new to me; I only ever set these things through u-boot bootargs=/dev/tty0
<robimarko>
Yeah, you can pass them via bootargs from U-boot
<oliv3r[m]>
I know during some arm hacking times, I used DEBUG_LL, where you basically only define UART address, push bytes out the uart
<robimarko>
That is what basically earlycon does
<oliv3r[m]>
i'm reading, yeah so why realycon> earlyprintk
<robimarko>
Earlycon is generic
<robimarko>
On some platforms it is just basically earlyprintk
<oliv3r[m]>
ok; sadly, no go :(
<oliv3r[m]>
setenv bootargs earlycon=uart8250,0xb8002000,115200n8 is what I used
<oliv3r[m]>
i can try compiling it into my kernel itself
<robimarko>
If you just pass the adress for 8250 then it assumes its 8 bit
<robimarko>
Which it obviously isnt
<robimarko>
uart[8250],io,<addr>[,options]
<robimarko>
uart[8250],mmio32be,<addr>[,options]
<robimarko>
uart[8250],mmio,<addr>[,options]
<robimarko>
uart[8250],0x<addr>[,options]
<robimarko>
uart[8250],mmio32,<addr>[,options]
<robimarko>
Start an early, polled-mode console on the 8250/16550
<robimarko>
UART at the specified I/O port or MMIO address.
<robimarko>
MMIO inter-register address stride is either 8-bit
<robimarko>
(mmio) or 32-bit (mmio32 or mmio32be).
<robimarko>
If none of [io|mmio|mmio32|mmio32be], <addr> is assumed
<robimarko>
to be equivalent to 'mmio'. 'options' are specified
<robimarko>
in the same format described for "console=ttyS<n>"; if
<robimarko>
unspecified, the h/w is not initialized.
<robimarko>
mmio32be should work
<oliv3r[m]>
let me try again :)
<oliv3r[m]>
sadly, no go :(
<robimarko>
You can try compiling those into the kernel
<oliv3r[m]>
yeah, doing that right now
<oliv3r[m]>
DEBUG_ZBOOT useful for anything? (Sounds new, sounds like something I wish I had 2 years ago when I was pushing out bytes just before the decompressor :)
<oliv3r[m]>
one things I see, is that I get 'CONFIG_BUILTIN_DTB' I thought the DTB was appended (in the realtek case)? Let me get some serial out first; then I can figure out if it is due to missing dtb
<oliv3r[m]>
so debug_zboot is probably not needed; as I'm not even getting 'Uncompressing Linux" so whatever is failing, is failing even before that ...
<oliv3r[m]>
nope, even with builtin bootargs, nada
xes has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
floof58 is now known as Guest67
floof58 has joined #openwrt-devel
<robimarko>
Thats really, really weird
Guest67 has quit [Ping timeout: 480 seconds]
<oliv3r[m]>
yeah, i'm patching compressed/uart-16550.c to add support for this board and enable zboot (without the generic mips patch, as that works) and if i can get zboot output, enable generic mips again
<oliv3r[m]>
not gonna go down the jtag route however :)
hurricos has joined #openwrt-devel
<hurricos>
gah
<hurricos>
I have returned
<oliv3r[m]>
wb! we still have that open MR ;)
<hurricos>
oliv3r: I know! It irks me! it's such a simple thing.
<hurricos>
oliv3r: I know what it was but can't find it, it's so old. Do you have a link:
<robimarko>
It was probably one of the mvebu ATF and U-boot discussions
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
bluew has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
<dhewg>
yeah, please don't waste my time with that guy
<robimarko>
Lets say that Pali knows what he is doing, but he has some strong views
<dhewg>
which would be okay, but then there's this inacceptable behavior on top
<robimarko>
He helped me a lot with various A3720 U-boot stuff, but its kind of his way or no other way
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
<dhewg>
his work/patches is just fine, he improved the upstream mvebu firmware situation alot
<dhewg>
but anyway, it got ugly. It's in PRs, but not worth your time either
<robimarko>
Oh yeah, he did wonders for Armada 37xx series in ATF, the tooling and U-boot
<robimarko>
I saw the "discussions" for ATF in U-boot
<dhewg>
yeah, tbh I never got it why it went where it went
<robimarko>
Me neither, it was a split in opionions
<robimarko>
But that happens everyday
<robimarko>
It would be crazy if we all agreed
<Znevna>
you guys agree on stuff too? :P
<robimarko>
It tends to happen ocasionaly
<Znevna>
I got to reading the ipq40xx ethernet and DSA support PR, got to half of it
<Znevna>
fun ride
<robimarko>
Only took a year or so
<f00b4r0>
well isn't open source all about "agree or fork off"? ;-}
<tmn505>
dhewg: robimarko: ok, I'll take a look at the discussion and try to figure out what happened there, as I rarely involve myself in GH dicussions. Worry not, I won't pry into it and stir it again.
<robimarko>
tmn505: Its pointless now, looks like he decided not not to care about OpenWrt related stuff anymore
<hauke>
vulpes2[m]: I did not look into the arm-trusted-firmware-rockchip
<hauke>
I migrated the otehr ATF builds to the trusted-firmware-a.mk to fix build with binutils 2.39
<hauke>
is the rockchip ATF still building?
<hauke>
vulpes2[m]: I do not have any rockchip hardware, would be nice if you could try
<tmn505>
robimarko: I like to have full view even when foul words were at play. Sometime You can convince people after some time has passed.
<robimarko>
tmn505: Couldnt hurt in this case
<dhewg>
tmn505: well, if you really wanna go there check my last 3 or so mvebu PRs. I still advice againt it though :P
<dhewg>
click those "comment hidden" thingies
* tmn505
prepares to be hit with rock made from words