goliath has quit [Quit: SIGSEGV]
<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
<vulpes2[m]> looks like I should send an MR to https://gitlab.com/openwrt/buildbot
G10h4ck_ has quit [Remote host closed the connection]
<vulpes2[m]> so it was already added by ynezz a year ago
xes__ has joined #openwrt-devel
<vulpes2[m]> no, actually swig was already fixed a long time ago on the gitlab container registry
<vulpes2[m]> but the failed workflows are pulling ghcr.io/openwrt/tools:latest, not the gitlab one
xes_ has quit [Ping timeout: 480 seconds]
<vulpes2[m]> so yeah I don't think I can fix this, someone who has push access needs to update ghcr.io/openwrt/tools
G10h4ck has joined #openwrt-devel
G10h4ck has quit [Remote host closed the connection]
<damex> does anyone here have access to banana pi r3? i wonder which dimensions are for heatsink mount.
xes has joined #openwrt-devel
minimal has quit [Quit: Leaving]
xes_ has joined #openwrt-devel
xes___ has joined #openwrt-devel
xes__ has quit [Ping timeout: 480 seconds]
xes has quit [Ping timeout: 480 seconds]
xes has joined #openwrt-devel
xes_ has quit [Ping timeout: 480 seconds]
xes_ has joined #openwrt-devel
xes___ has quit [Ping timeout: 480 seconds]
xes__ has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
<philipp64> stintel: how often are you cycling session keys?
xes has joined #openwrt-devel
xes_ has quit [Ping timeout: 480 seconds]
xes__ has quit [Ping timeout: 480 seconds]
xes_ has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
felix has quit []
felix has joined #openwrt-devel
tomn has quit [Quit: Lost terminal]
tomn has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
<owrt-2102-builds> Build [#53](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/40/builds/53) of `ramips/mt7621` completed successfully.
<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
Tapper1 has quit [Ping timeout: 480 seconds]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
goliath has joined #openwrt-devel
f0g has joined #openwrt-devel
<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
<rmilecki> oh, wait, "./scripts/feeds install -a -p packages" doesn't reinstall package
<robimarko> Think you need to pass -f to override the installed ones
danitool has joined #openwrt-devel
<oliv3r[m]> ynezz: here's the full error; it's not much more :p https://paste.debian.net/1265930/
<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]: arch/mips/Makefile: cflags-$(CONFIG_CPU_MIPS32_R2)+= -march=mips32r2 -Wa,--trap
<robimarko> So, it should pass --marc=mips32r2
<oliv3r[m]> but sadly, for some reason, i get the error I pasted before :( but I don't know why, as this was working fine for months
<oliv3r[m]> yesterday, it all of a sudden broke; and I don't know why
<oliv3r[m]> (i was changing order of commits, rebasing a lot of course)
<robimarko> What does the kernel config say?
<oliv3r[m]> when greppin for MIPS32 what I just pasted from there
<oliv3r[m]> # CONFIG_CPU_MIPS32_R1 is not set... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/nVVDnTdPfLzanHwUgmDqAAOP>)
<oliv3r[m]> but doing 'set mips32r2' seems to work for some reason; so at least that's good :)
<robimarko> Hm, so no idea how is it emiting the wrong march
<nbd> maybe cflags vs asflags mixup?
<oliv3r[m]> Maybe, but I didn't even go near that stuff :S
<robimarko> nbd: aflags are set to the same value as cflags
<robimarko> KBUILD_AFLAGS+= $(cflags-y)
<robimarko> KBUILD_CFLAGS+= $(cflags-y)
<robimarko> cflags-$(CONFIG_CPU_MIPS32_R2)+= -march=mips32r2 -Wa,--trap
<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]> I know that https://gitlab.com/olliver/openwrt/openwrt/-/commit/9a942a22865 seems to introduce most of this mayhem, some makes sense, some I don't see why :
xes__ has joined #openwrt-devel
xes__ has quit []
xes_ has quit [Ping timeout: 480 seconds]
<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]> got the latest u-boot release fully working for rk targets https://github.com/openwrt/openwrt/pull/11669
xes has joined #openwrt-devel
<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
floof58 is now known as Guest56
floof58 has joined #openwrt-devel
Guest56 has quit [Ping timeout: 480 seconds]
xes__ has joined #openwrt-devel
<aiyion> mrkiko: this is the last build from dec 24th: https://bpa.st/VLDLA
<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...
<mrkiko> aiyion: I guess you're using https://github.com/gl-inet/gl-infra-builder as a starting point
<aiyion> it crashes reliably at that point.
<mrkiko> aiyion: or did you get the mt7681 patches another way ?
<aiyion> which are "the mt7681 patches"?
xes__ has quit [Ping timeout: 480 seconds]
<aiyion> xiamois ax6000 is supported by OpenWrt and running on a mt7986a
<aiyion> the brum2 is runnign on the mt7986b, which is absically a but with reduced speed and reduced features I do not use.
<aiyion> *brume2
<mrkiko> aiyion: oh, sorry - I was thinking it was mt7681. I am schimming trough the patches in gl-inet infra repo, but am not seeing anything obvious
<aiyion> glinet has not pushed the brume code yet, I think.
<mrkiko> aiyion: in the infra repo you mean?
<mrkiko> aiyion: I see various references to mt2500 which should be the brume2
<aiyion> indeed, thanks
<aiyion> must have had a typo the first time I searched
<mrkiko> aiyion: but something seems wrong on my side - if you look in the README you can find things like
<mrkiko> README.md: ./scripts/gen_config.py target_mt7981_gl-mt2500 luci ...
<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
minimal has joined #openwrt-devel
xdarklight has quit [Quit: ZNC - https://znc.in]
xdarklight has joined #openwrt-devel
xdarklight has quit [Quit: ZNC - https://znc.in]
xdarklight has joined #openwrt-devel
Tapper has joined #openwrt-devel
<vulpes2[m]> do a targetclean instead
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:
<hurricos> Which maintainers are the most active? It's a super simple change that anyone can review pretty easily.
SlimeyX has quit [Ping timeout: 480 seconds]
<oliv3r[m]> ansuel has been, but not much int he past few days (hollidays of course)
<hurricos> of course.
<owrt-snap-builds> Build [#427](https://buildbot.openwrt.org/master/images/#builders/72/builds/427) of `imx/cortexa9` failed.
Lynx- has joined #openwrt-devel
<Lynx-> jow I think the example here: https://openwrt.org/docs/techref/initscripts#custom_commands for multiple line variable is wrong and should be changed to something that works
<Lynx-> This works: https://pastebin.com/T59UC0jr
xes has joined #openwrt-devel
idiot42 has joined #openwrt-devel
idiot42 has quit []
soxrok2212_ has joined #openwrt-devel
soxrok2212 has quit [Read error: Connection reset by peer]
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
zer0def has quit [Ping timeout: 480 seconds]
<tmn505> dhewg: can You point me to a discussion which led to this comment: https://github.com/openwrt/openwrt/issues/11661#issuecomment-1369120143 ?
zer0def has joined #openwrt-devel
<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
<hauke> ynezz: this looks good: https://github.com/openwrt/openwrt/pull/11672
<hauke> could you please merge it or should I?
robimarko has quit [Quit: Leaving]
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
<ynezz> hauke: done
Borromini has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
danitool_ has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
bluew has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
Borromini has left #openwrt-devel [#openwrt-devel]
MAbeeTT2 has joined #openwrt-devel
MAbeeTT has quit [Ping timeout: 480 seconds]