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
<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 :/
<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?
<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
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)
<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
<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>
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