nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Gaspare has quit [Quit: Gaspare]
<Grommish> https://www.toptal.com/developers/hastebin/adebaqebox.rb Can anyone confirm these errors are becausse the SOC doesn't support hardfloat?
nlowe has joined #openwrt-devel
<Habbie> Grommish, i don't know, but the icons sitting over the paste will make this hard to read for anybody
<Grommish> Ah, Stupid hastebin they used to be good :D
<Habbie> better :)
EqUaTe has quit [Quit: Someone should have labelled the future as 'some assembly required'!]
<Grommish> Appreciated :)
<Habbie> :)
<Grommish> I'm just going to force it all to sf and see what happens
EqUaTe has joined #openwrt-devel
<Habbie> ack, good luck
<Grommish> I keep hearing about Openwrt including LLVM.. is it a host package already?
<Habbie> i only know about LLVM/OpenWrt in eBPF context
<Habbie> but i don't know much
<Grommish> rust-lang uses LLVM, and I'm pulling it as part of the source tarball, but I am getting questions about using the one you're referring to.. and I can hook an external LLVM, but I dunno where it's at
<Grommish> Package-wise
<Grommish> I'll have to keep looking
hanetzer has quit [Quit: WeeChat 3.3]
hanetzer has joined #openwrt-devel
<stintel> oof, dawn seems to kick all clients when it restarts, and since it crashes and autorespawns ...
<stintel> that gives funny situations as my esp32s in my AC units reconnect, they beep because they go unavailable in hass and when they become available again hass restores the state :P
<Habbie> what's dawn?
<Habbie> and, state, even if you changed things via IR? :)
<stintel> especially because it's via IR
<stintel> because hass can't know its actual state, it sends the IR event for the last known state
<Habbie> uhuh
<stintel> it's not perfect but it works, and the esp32-c3 are inside the AC unit powered of the control unit so I'm happy :)
<Habbie> :)
bluew has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
<mrkiko> anyone knows an easy way around sysupgrade closing all shell sessions?
<mrkiko> Need to have more visibility in what happens when I do sysupgrade
Gaspare has joined #openwrt-devel
<mrkiko> well, ok, it would be a problem due to inability to umount root fs.
<stintel> mrkiko: serial console is the only option
<stintel> this is a terrible limitation of sysupgrade :(
<mrkiko> eheh :D bad news for me
<mrkiko> stintel: never tought about it until I discovered it's not working as expected - even when I specify the -n (and -p) flags on an eMMC based device (gl-b2200) the overlay remains intact. and now I am trying to understand if the image is actually written to eMMC. I will understand it shortly, but the overlay thing ...
<mrkiko> ok, would say no; the only way to upgrade at the moment is dd :D
spacewrench_ has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
<hurricos> Is it possible to put multiple items in a chosen in a dts?
<stintel> I found out why chronyd SIGILLs on the m300 :P
<stintel> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=blob;f=toolchain/musl/patches/991-powerpc64-drop-inline-asm-sqrt-and-sqrtf.patch;h=5c7f0b780ec571ef94f73963f71852209d425ba7;hb=bf40c955926f4cece90414648bd0628040c433f8
<hurricos> wtf
<stintel> :D
<hurricos> just based on that commit line
<hurricos> wtf
<hurricos> mrkiko: It's ubi, yeah?
<hurricos> stintel: Do you know RE: multiple chosens in a DTS?
<hurricos> I just discovered the problem (I think) with the AP3825i not booting, I dug through the platform source and the default defice tree and I think it's because
<hurricos> linux,memory-limit = <0xff7f000>;
<hurricos> i.e. "something critical is mapped past there"
<hurricos> I saw this with P2041RDB
<hurricos> but I don't want to give up my chosen for bootargs :(
Gaspare has quit [Quit: Gaspare]
<hurricos> oh heck, let's just try it
<hurricos> what's the worst that can happen
<Grommish> hurricos: That's my motto too
<hurricos> worst that can happen is that it doesn't work and I go back to my C200 and spend another 7 hours trying to figure out ram init on Marvell Armada 370
<hurricos> which is pretty bad tbh
<mrkiko> hurricos: no, f2fs
<Grommish> And, this R8000 build finished with ARMv7_musleabi rather than the hf.. hmm
<hurricos> mrkiko: Oh, so cat /proc/mtd | grep ubi is empty, yes?
<hurricos> all one big partition that is detected as f2fs by something else
<hurricos> it builds!
<hurricos> of course it doesn't boot lmao
<Grommish> rsalvaterra: I think I figured out the Hard-float define :) ifeq ($(FEATURES), $(filter fpu, $(FEATURES)))
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hurricos> oh fml
<stintel> yeah :P
<hurricos> the device tree blob I scraped out of the uImage
<hurricos> is not complete
<stintel> I need to figure out how to write if (__hwcap & PPC_FEATURE_HAS_ALTIVEC) in ppc64 assembly :/
<hurricos> it accesses memory ... and then pulls memory.reg
<stintel> to properly fix musl for e5500 / firebox m200 (and a bunch of other devices)
<hurricos> which is empty in my device tree
<hurricos> stintel: not mpc85xx, I trust?
<hurricos> oh wait
<hurricos> this is just ppc64
victhor has quit [Ping timeout: 480 seconds]
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
rua has quit [Quit: Leaving.]
slh has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<hurricos> > opens file from dump called error.log
<hurricos> > skims file: "... DTS ..."
* hurricos focuses his eyes
<hurricos> > "DTS: Add dts for single core version of P1020RDB"
* hurricos gulps. grasps around for his glasses
* hurricos attepmts to re-read
slh64 has joined #openwrt-devel
<hurricos> > "... Cannot open linux-2.6.35-qoriq-DTS-Add-dts-for-single-core-version-of-.patch for write: File exists ..."
<hurricos> What in the fuck is a "single core version of P1020RDB"
<hurricos> what
<hurricos> That's not
<stintel> :P
<hurricos> that's illegal
<stintel> so we're kinda working on the same thing :D
<stintel> although maybe p1020 is not ppc64
<hurricos> ppc32 thankfully
<stintel> well look at that, my assembler code compiles 😂
* stintel prepares to see things go up in smoke
<hurricos> Hold on, I'm going to boot the stock kernel and try /proc/cpuinfo
<hurricos> Freescale is going to hear more than words from me if this is actually a single-core machine
<hurricos> stintel: Considering how many machines have gone to the wayside because of lack of altivec compiler support
slh has joined #openwrt-devel
<stintel> I'm about to fix that! :P
<hurricos> yeah.
<stintel> kind of have to, if I want to make openwrt work on the m200 and the bsap3040 Slimey sent me
<hurricos> OK, It's *confirmed* dual-core. https://paste.c-net.org/ColbyRomances
rua has quit [Ping timeout: 480 seconds]
<stintel> oh, spotted a mistake
<stintel> and looks like I lost my working miniupnpd commit
<stintel> fml
<hurricos> D:
<hurricos> I hate when that happens ....
<stintel> can probably find it in reflog
<hurricos> And either I stash and forget the stuff, or I just create another tree and run out of space under /devel T _T
<stintel> but yeah that's what happens when you have multiple trees with multiple branches with WIP and you need to merge several branches together to have something that will work on your testing device
<stintel> I wanted to send out v2 of qoriq but the fsrqt* missing is a problem
<stintel> but if I can get that in master that's one big hassle less in my build procedure
rua has joined #openwrt-devel
<stintel> interesting, it built fine on the buildbots
<stintel> Configuring compilation for [OpenWRT] [SNAPSHOT] with [iptables] firewall software.
<hurricos> stintel: buildbots tend to "give up" easily, don't they
<hurricos> or ignore a lot of errors.
<stintel> nah, build system is just terribly fragile and every 3rd build something messes up and you need to rm -rf tmp or make package/foo/clean to fix package bar
<stintel> actually I meant to say it built fine in CI
<stintel> /lib/upgrade/do_stage2: line 59: partx: not found
<stintel> /lib/upgrade/do_stage2: line 60: partx: not found
<stintel> u-oh
<hurricos> lol
<stintel> ok fortunately it was harmless
<stintel> I had increased the root partition size to play with gcc on the device
<hurricos> buildsystem says: "I don't like this toolchain. I'm going to get rid of it with some nice `rm`s." "Corrupted your packages? What's a packages?"
<stintel> :P
<hurricos> I don't get what makes this board not boot.
<hurricos> It's something very early. Maybe memory initialization? Maybe I'm allocating memory somewhere I can't? I just don't see it in the original fw / source.
<hurricos> Other than the ff7f000 cutoff.
<hurricos> I don't see anything in u-boot that's manipulating the device tree.
<hurricos> Unfortunately the vendor kernel is too old to have /proc/device-tree
<hurricos> (2.6.32)
<stintel> dafuq
<hurricos> ?
<stintel> and I was ranting about rsdk 3.18 qsdk 4.4 :D
<hurricos> Sorry, 2.6.35. By "vendor" I mean the OEM, not Freescale lol
rua has quit [Quit: Leaving.]
<stintel> I can do you one better even 😂
<stintel> Linux GSE200M 2.6.27-SPEAr310 #80 Fri Jan 13 11:22:09 CST 2017 armv5tejl
<hurricos> I can't see how the board is different from the other P1020 boards I have (AP 330, AP 370, WS-AP3825i)
<hurricos> err
<hurricos> WS-AP3710i
<hurricos> eww
felix has quit [Ping timeout: 480 seconds]
<stintel> it's the snmp module in my UPS
<stintel> you would almost unplug it from the network and use a pi or esp and modbus
<stintel> but these things are in a management vlan so I don't care too much
felix has joined #openwrt-devel
<hurricos> blehh
<hurricos> Is /dev/mem anything interesting?
<hurricos> doesn't appear to be readable; dd gives me `dd: /dev/mem: Bad address`
<hurricos> it really just has to be something stupid in early kernel init that's wrong. That's almost exclusively memory
Tapper has joined #openwrt-devel
Tapper1 has quit [Read error: Connection reset by peer]
<hurricos> Maybe if I gut as much of the tree as I can, I'll find something that was just being misparsed?
<hurricos> Nah, if anything it'll be in the platform ifle.
<stintel> nice the assembler code also does not crash at runtime
* stintel fetches the m200
<hurricos> stintel: in all of the cases you've tested it doesn't crash :^)
* hurricos hides behind sufficiently large furniture to defelct an m200
<stintel> well, the m200 would crash right after loading init
<hurricos> back in my day we had to debug kernel initialization without a console
felix_ has joined #openwrt-devel
<hurricos> we had to bit-bang morse-code out of the LED
<hurricos> (I say, dreaming of actually being able to debug something rather than just having it NOT BOOT AT ALL)
<hurricos> eTSEC doesn't require firmware, does it? Could be that this u-boot isn't loading the f/w when it shoudl be
<dwfreed> hurricos: /dev/mem allows for direct memory access; however, cat and dd without seeking won't work
felix has quit [Ping timeout: 480 seconds]
<dwfreed> because 0x0 is marked as unreadable
<hurricos> ah, ok.
<hurricos> would it be a problem specifically with FIT images, maybe?
<hurricos> Or the kernel being too large ...?
<hurricos> No, it boots from fit
<hurricos> oddly enough, busybox dd cannot seek /dev/mem :P
<hurricos> perhaps it tries to access the first page anyhow
<hurricos> (it being busybox)
Tapper1 has joined #openwrt-devel
felix_ has quit [Ping timeout: 480 seconds]
Tapper has quit [Read error: Connection reset by peer]
felix has joined #openwrt-devel
<hurricos> I probably used `seek` and not `skip`.
<hurricos> No, the original kernel uses a uimage ._.
<hurricos> hmmmmmmmmmmmmmm
<hurricos> the oem kernel doesn't boot with my fdt :^)
<hurricos> and my kernel doesn't boot with the oem's fdt.
<hurricos> to the surprise of nobody.
<stintel> :D
<hurricos> What *is* so special about the board?
<stintel> I'm gonna have to invest in a new workstation soon
<hurricos> stintel: get a rack server
<stintel> these 40 cores don't cut it anymore :P
<stintel> actually I was considering making a thin client with the hifive unmatched
<stintel> but I'd need to get a low profile GPU that can properly drive 5120x1440
<hurricos> stintel: here's what you need https://www.ebay.com/itm/114855582139?hash=item1abded19bb:g:gZoAAOSwEVNgpbWg
<hurricos> 96 threads :^)
<stintel> I have 80 now, which is nice
<stintel> but, the clock speed is low
<stintel> so all this single-threaded work is slooooow
<hurricos> jfc, 80 on what?
<stintel> Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
<stintel> dual
<hurricos> ooh
<stintel> { cat usr/initramfs_data.cpio | lzma e -d20 -lc1 -lp2 -pb2 -eos -si -so; :; } > usr/initramfs_inc_data
<stintel> if it's making an initramfs it's almost ready
<stintel> man if that works I'm going to be happy
<stintel> also go to bed
<stintel> before I know it I will be working on altivec optimized memcpy for musl? :D
<hurricos> well, seeing as the oem kernel doesn't boot with my dts, I know at least one thing now
<hurricos> whatever it is that's preventing it from booting
<hurricos> is both a diff in the decompiled dtb's
<hurricos> AND is mentioned in the platform setup somewhere
<hurricos> considering how many `#ifdef CHANTRY`s there are
<hurricos> this is going to take a while to find
<hurricos> lol
<stintel> interesting. m200 boots fine
<hurricos> :o
<hurricos> but?
<stintel> now the question is, does the m300 still use altivec in setjmp longjmp :)
<spacewrench> if you've built a kernel with headers at /sys/kernel/kheaders.tar.xz, is there an easy way to unpack those into /usr/include or /usr/local/include so that #include <linux/foo.h> (and all the files included from there) are in the right place?
<stintel> actually, if I would add fsqrt in the block with altivec instructions I would get SIGILL on the e6500 if they're still being used
<hurricos> stijn's destiny is to port boards, you better bet he will / but his assembler's altivec addiction is SIGILL
<stintel> 😂
<hurricos> spacewrench: not sure :(
<hurricos> I ma going home
<hurricos> biking 3 miles over ice yay
<hurricos> staying out this late was not a good choice T _T
<stintel> safe drive
<spacewrench> ride safe
<hurricos> thank you all
<hurricos> I hope to return tomorrow in one piece so I can hassle danitool to give me a working Armada 370 memory trainer / u-boot build procedure
<stintel> bah, it doesn't work at all
<stintel> but for some reason I'm not hitting the altivec instructions after init
<stintel> oh wait
<stintel> dumbass me
<stintel> lol, I add the fsqrt in the wrong branch *facepalm*
<neggles> stintel: E5-2699P v4! customized version of the E5-2699v4 with a *300W* PL2, 22c44t, 3.0GHz base, 3.6GHz all-core turbo :P
<neggles> that's about as good as 2011-3 is getting, though
<stintel> o_O
<neggles> hehehe, yeah, it was made for a cloud provider
* stintel checks ebay
<neggles> they're not hugely easy to come by, but they do show up here and there
<stintel> there's a pair for sale in italy
<stintel> ah no
<stintel> not the P version
<neggles> yeah, same actual peak clocks, just 300W TDP so it'll boost for eternity
<neggles> I suspect you'd have more luck on taobao, they were probably made for alibaba's watercooled cloud stuff, but clearly not a high-volume product :(
<neggles> there's always the E5-2687W v3/v4 but people want insane money for those
<neggles> (and only 12c)
rua has joined #openwrt-devel
<hurricos> I made it home safe :D
<stintel> hurricos: great
<stintel> nbd: unfortunately I just had another stall
<stintel> it seems that it triggers easier with a client that is farther away from the AP
<stintel> explains why I couldn't really reproduce it in my office
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
snh has quit [Remote host closed the connection]
snh has joined #openwrt-devel
snh_ has joined #openwrt-devel
danitool has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<nbd> stintel: please try copying https://nbd.name/900-txq_test.patch to package/kernel/mac80211/patches/subsys
dedeckeh has joined #openwrt-devel
victhor has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
snh_ has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
embargo has quit [Quit: ZNC - https://znc.in]
snh has joined #openwrt-devel
snh has quit [Quit: ZNC - http://znc.in]
embargo has joined #openwrt-devel
snh has joined #openwrt-devel
minimal has joined #openwrt-devel
snh has quit [Quit: ZNC - http://znc.in]
snh has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
goliath has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
PtitGNU has quit [Quit: Quassel terminated!]
PtitGNU has joined #openwrt-devel
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
nlowe has quit [Ping timeout: 480 seconds]
fda has quit [Quit: ZNC - https://znc.in]
fda has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<hurricos> danitool!
<hurricos> I need to heavily pick your brain about Armada 370 U-boot
<hurricos> do you mind if I?
<hurricos> I have a board whose u-boot is uninterruptible and is stored on TSOP-48 NOR flash
<hurricos> I was wondering if you knew what it'd take to port said board to U-boot along the same lines as the Clearfog or Helios4, so that we can supply a kwboot-able boot rescue image
<hurricos> It has the same SoC and amount of RAM as the Globalscale Mirabox FWIW, but when I send the recovery.bin that Willy Tareau provides for the Mirabox over kwboot (https://wtarreau.blogspot.com/2013/02/mirabox-much-better-than-guruplug.html), the board becomes extremely slow once the RAM training program has been sent
<hurricos> I suspect because kwboot is compensating for the RAM training program outputting stuff on serial
<hurricos> I am going to take another stab at it today and see if I can just get a shell on the device, but if not I will have to try and compile for the board.
<hurricos> is it possible to ask the kernel to put its kernel log ring buffer in a particular part of RAM using the device tree?
<danitool> hi hurricos, I don't remember all details about Armada 370, do you know if the amount of RAM is hardcoded in Uboot?
<hurricos> If not, is it possible to guess at the location of the ring buffer? I know kernel addressing is usually randomized and I don't exactly have an easy way to find virtual to physical ring buffer mapping
<hurricos> danitool: Not sure, but fortunately I have the same amount of RAM as the Mirabox
<danitool> did you test the Uboot recovery image from my Linkstation?
<hurricos> danitool: Yes, I used all of those! It was funny, occasionally they'd work and occasionally they wouldn't. I suspect sometimes kwboot was successfully ignoring the output, sometimes not
<hurricos> but that was just the early init, eventually it all crashed. Probably some hardware buttons being pressed that shouldn't be
<hurricos> That's actually why I came to you fwiw
<hurricos> One of the things I did was actually to kwbimage -x from yours to get the ram training and combine it with another u-boot. Ultimately I think part of the problem is that I don't have a copy of this board's u-boot payload
<hurricos> It *is* the same SoC thankfully, MV6710 / 88F6707
<danitool> did you give a try to barebox bootloader?, AFAIK it has official support for Armada 370
<hurricos> danitool: I have not even got a device tree to start off with :P
<danitool> in fact the first bootable recovery image I was able to use was compiling a barebox bootloader
<hurricos> Ah ...
<danitool> then I figured out about the possibility of splitting the bootloader for joining again the header an the payload but for booting via serial interface
<hurricos> I did check out barebox a little bit. I unfortunately got stuck finding a simple way to build a toolchain, I was assuming RHEL's gcc might not be workable
<hurricos> I am somewhat spoiled by OpenWrt. I guess I could dig a bit and pick the right arch and just ask OpenWrt to build me a toolchain
<danitool> I think the toolchain from could be used
<hurricos> but ultimately I'm very unfamiliar :S
<danitool> from Openwrt*
<hurricos> is is just a couple of exports for ARCH, CROSS_COMPILE and CROSS_COMPILE_BH?
<hurricos> once I have the toolchain built, that is?
<hurricos> or are there other exports needed?
<danitool> I don't remember the exports
<hurricos> ah, ok.
<danitool> hurricos: these were my exports for barebox (found in my notes)
<danitool> export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
<danitool> export KBUILD_OUTPUT=../build
<danitool> export ARCH=arm
<danitool> make mvebu_defconfig
<danitool> export STAGING_DIR=/run/media/dani/DT01ACA3/OPENWRT/snapshot-linkstation/staging_dir
<danitool> make
<danitool> well this has no much sense to me right now
<danitool> btw compiling barebox it's easy once you give it the path of the right toolchain
<hurricos> Thanks, I'll get back to this. I just found a huge lead on my non-working P1020 board
<hurricos> The stock U-boot uses a WDT and some reserved memory to detect whether the watchdog caused the last reboot
<hurricos> in particular I can use the WDT to soft reset and use the System.map (https://support.xilinx.com/s/question/0D52E00006hpihR/linux-kernel-hangs-after-allocatting-dma-contiguous-pool-on-zynq-7000?language=en_US) to read the kernel message log using U-boot :D
<hurricos> I can finally find out what is crashing it without a console : _;
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
aiyion_ is now known as aiyion
Borromini has joined #openwrt-devel
<hurricos> fml
<hurricos> __log_buf is in virtual memory
<hurricos> Oh, CONFIG_KERNEL_START is usually c0000000 on ppc: http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis
<hurricos> fml I cannot catch a break. Something zeros it out.
pmelange1 has joined #openwrt-devel
pmelange1 has left #openwrt-devel [#openwrt-devel]
<hurricos> I don't get it. If the kernel decompresses to 0x0, what exactly does System.map actually do for me?
<hurricos> I don't see how System.map can be correct ... oh wait, it IS the same thing as the kernel
<hurricos> actually, I odn't think things zero out the buffers, I think they're just empty because the kernel never starts
<hurricos> blocktrron: Do you recall any hiccups in the Ws-AP3710i port?
<Grommish> How prevelant are PPC targets?
<hurricos> Not very, frankly
<hurricos> The only ones you'll ever see are Freescale. apm821xx is an outlier
<Grommish> Didn't think so. I'm trying to build LLVM for it and hitting ASM issues, so I was going to skip PPC if it wasn't worth it
<hurricos> Yes, you should
<hurricos> ppc32 also does not have golang
<Grommish> I was making rustlang for it
<Grommish> PPC is 32, Powerpc64 is 64 bit?
<Grommish> I don't know anything sbout the arch
<hurricos> Ditto
<hurricos> I don't think 'ppc' refers specifically to 32 or 64
<Grommish> I've got a powerpc and a powerpc64 tuple. I'll either dig it out with a rusty spoon, or just set an ARCH limitation for it in the package until I can
<hurricos> you will see more refrences to IBM POWER ISA when you spell out "power". But I see kernel builds for 64-bit PowerPC as ppc64
<hurricos> Yeah, I just haven't heard good things about dealing with arch-specific POWER stuff. stintel was working on qoriq (ppc64) and running into kernel crashes
<Grommish> powerpc64_unknown_linux_musl, powerpc64le_unknown_linux_musl , powerpc_unknown_linux_musl
<stintel> those are out the way, mostly
<Grommish> Are my choices
<stintel> except hardened usercopy
<hurricos> or maybe userland crashes actually
<hurricos> I don't know
<hurricos> let him tell you :P
<stintel> I have powerpc64-openwrt-linux powerpc64-openwrt-linux-musl for qoriq
<stintel> powerpc64le-gentoo-linux-musl for power8
<stintel> hurricos: can you check in mpc85xx staging_dir what it's called ?
<stintel> I don't have mine anymore :P
<stintel> wait
<stintel> no I don't
<hurricos> powerpc_8540, perhaps?
<hurricos> e.g. `staging_dir/target-powerpc_8540_musl'
<stintel> hurricos: check in the gcc/ symlinked dir there
<stintel> target-powerpc_8540_musl is just what openwrt makes of it
<hurricos> powerpc-openwrt-linux-musl
<stintel> ok so there we have the 3 options :)
<hurricos> So these are, what, different toolchain sources, yes?
<hurricos> Just to have learned something from this conversation ...
<stintel> powerpc-openwrt-linux-musl = ppc32, powerpc64-openwrt-linux-musl = ppc64 (big endian), powerpc64le-openwrt-linux-musl = ppc64 (little endian)
<stintel> it's just the toolchain compiled for that specific powerpc arch
<hurricos> OK, I see. Just want to keep in mind to myself that I could check out the gentoo toolchain if barebox won't compile with OpenWrt's toolchain
<stintel> qoriq is be only, power 8 can do both be and le afaik
<hurricos> bareboot*
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
felix has quit [Ping timeout: 480 seconds]
felix has joined #openwrt-devel
felix has quit [Ping timeout: 480 seconds]
<Slimey> who do you love when you come undone, hi :P
felix has joined #openwrt-devel
<hurricos> Huh ...
<hurricos> Maybe the kernel remaps __log_buf elsewhere?
felix_ has joined #openwrt-devel
felix has quit [Ping timeout: 480 seconds]
<f00b4r0> stintel: qoriq is 32bit powerpc-based, right? I thought all powerpcs (except the 970) were bi-endian capable?
<hurricos> qoriq is 32 or 64
<stintel> 64
<stintel> afaik
<hurricos> f00b4r0: e.g. apparently P1020 is QorIQ
<stintel> well, it can do 32 of course but I believe all of them are 64 bit capable?
<stintel> maybe I don't remember well
<f00b4r0> still based off PPC core, should be bi-endian
<stintel> f00b4r0: qoriq ppc is not bi-endian
<f00b4r0> stintel: good to know
<f00b4r0> also a bit surprised that there would be a 64bit ppc router SoC, unless of course there's a use for >4GB ram in that context
<stintel> I am quite liking mine :)
<f00b4r0> :)
<stintel> but landmines ...
<f00b4r0> I liked PPC a lot, but the last time I touched it was 10+ years ago
<f00b4r0> back then there was no point in running a 64bit userspace if you didn't need >4GB RAM for anything, it brought not performance benefit, and even sometimes the opposite
<Grommish> stintel: What target is that powerpc64le?
<stintel> Grommish: qoriq (WIP)
<stintel> Grommish: ah no
<stintel> there is no such thing in OpenWrt at all
<stintel> just gave you example of what it would be named
<Grommish> Ah. I've got a powerpc64le_musl tuple for it, which is why I was interested
<f00b4r0> ppc(64)le should be almost non-existent nowadays
<f00b4r0> back in the days some were running ppc in LE to work with some GPUs
<f00b4r0> doubt this would still be the case today :)
<f00b4r0> oh, and running WinNT also, IIRC
<Grommish> They have an Itainium instruction set?
<f00b4r0> of course not?
<Grommish> It was outlining both RISC and IA
<Grommish> I though the IA was the Itainium shortword
<f00b4r0> I don't follow you
<stintel> f00b4r0: eh? linux is moving from ppc64 to ppc64le ?
<f00b4r0> Itanium is (well, "was") IA64
<stintel> I mean most distros
<f00b4r0> stintel: are they? Boy have I lost touch then
<Grommish> Ok.. I'm getting user-level cache memory control (dcbx/icbx) ASM errors (along with sync).. But I see it in the instruction set
<Grommish> I refuse to learn PPC MASM to get it work.. I think this is now backburnered :D
<hurricos> Grommish: :^)
<hurricos> OK, I'm officially taking drastic measures
<hurricos> after finding not a single BSS segment from System.map that is non-zero in RAM on the system post-soft-reset, I am now md dumping the entire kernel memory space to a screen.log file
<f00b4r0> stintel: I assume it's for better "compatibility" with the x86 world
<hurricos> which I will then decode and cmp to the actual kernel
<hurricos> I swear to god if I don't find a single thing different I don't know what I'll do
<f00b4r0> Grommish: these instructions are x86
<hurricos> it's not just a matter of the kernel crashing, it's literally U-boot just not actually starting the kernel
<Grommish> f00b4r0: Which?
<f00b4r0> the ones from your pastebin
<Grommish> f00b4r0: Maybe, but check Pg24: https://www.nxp.com/docs/en/white-paper/POWRPCARCPRMRM.pdf
victhor has quit [Remote host closed the connection]
<Grommish> I'm way outside my knowledge base. I dunno if I'm going to dig much further for what is honestly a small target base
<f00b4r0> Grommish: i may be confused. Haven't touched ppc assembly in eons
<Grommish> f00b4r0: I never have :( and I don't have one for testing, but if I can get it build, i'll let someone else play with it
<f00b4r0> the target registers look x86-ish to me
<Grommish> It's an llvm error, I may just go pester them
<Grommish> I already bypassed their -D__ppc__ demands finally
<Grommish> f00b4r0: To be clear, I dont know any arch ASM.. I'm just too naive to know better and to stubborn to stop when I should
<f00b4r0> well it looks like you have some mixed bag of ppc instructions with x86 registers
<f00b4r0> I doubt your toolchain supports that :)
<Grommish> powerpc_unknown_linux_musl is a predefined tuple
<Grommish> LLVM is going to be the bane of this project
<Grommish> Ah well
<f00b4r0> Grommish: %rax, %rdx etc: these are x86 registers names, which is what prompted my initial remark
<f00b4r0> something is utterly wrong with whatever you're trying to compile here
<Grommish> LLVM for powerpc
<Grommish> within the build system
<Grommish> it's for rust-lang
<Grommish> I'll just come back to it after I get the rest of the targets finished
<f00b4r0> well, something is clearly broken.
<Grommish> For all i know, it never was intended to work like I'm doing it, so i'm not surprised
<Grommish> Appreciate the look though!
<f00b4r0> np yw
felix_ has quit [Ping timeout: 480 seconds]
felix has joined #openwrt-devel
<stintel> nbd: and another stall
<Borromini> stintel: you testing an MT7613?
<stintel> yes
<stintel> couldn't repro it in my office, happens more easily with a client in the bedroom (farther away from the AP)
<Borromini> ok
<Borromini> i'm on the testing repo, on 21.02 though
<Borromini> and with the patch nbd shared https://termbin.com/7f83
<stintel> there are 2 more
<stintel> 27|11:27:20 < nbd> stintel: please try copying https://nbd.name/900-txq_test.patch to package/kernel/mac80211/patches/subsys
<stintel> how often do these stalls happen for you ?
<stintel> enough for the wife to complain ? :P
<Borromini> so far not yet :P
<Borromini> got thrown off the wifi today though
<Borromini> had to reconnect myself
<Borromini> i'll grab both and do a re-run tomorrow maybe
<Borromini> gotta check with my wife when she's homeworking then maybe roll back the firmwares to be on the safe side too...
* Borromini doesn't want any trouble
<Borromini> god knows we're heading for another lockdown and I won't hear the end of it :P
<Borromini> fighting my disappearing packets on bonded interface atm :(
pmelange has joined #openwrt-devel
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #openwrt-devel
minimal has quit []
pmelange has left #openwrt-devel [#openwrt-devel]
lmore377 has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<hurricos> I have output!!!
<hurricos> oh lol it's an oops
tmn505 has quit [Remote host closed the connection]
tmn505 has joined #openwrt-devel
bluew has quit [Quit: Leaving]
<stintel> argh, build failing due to github
<Habbie> just quit for the day
<stintel> grrr why does it even need to contact github if the thing is supposed to be in dl/
spacewrench_ has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]