<dwfreed>
I let somebody else do all the adventuring
<dwfreed>
So thanks for all the effort
<dwfreed>
that firebox m300 works a treat
<stintel>
ah happy to hear it :)
<stintel>
I
<stintel>
I'll be looking at some new stuff probably in the nearish future
<dwfreed>
might see if I can get another one for here
<robimarko>
That EAP looks quite neat
<stintel>
got approval for the real estate loan, notary next week, so I'll be moving to a house soon
<stintel>
big plans there :P
<dwfreed>
nice!
<robimarko>
congrats
<stintel>
it's <2km from a datacenter, considering dark fiber and going nuts :P
<dwfreed>
rofl
<stintel>
robimarko: yeah I spotted it last week, there is a forum post asking about it, I looked up some of the components, looked like it should be easy to support, didn't consider serial console being such a PITA though :P
<robimarko>
Have they connected TX or left it up to you to add a resistor?
<stintel>
at this point no idea, I'll try some things when the cleaning lady is done with the office
<stintel>
at least the enclosure is super easy to open, 6 screws, not hidden, no clips, it just straight opens after removing those 6 screws
<robimarko>
That is a welcome break from glued together cases
<dwfreed>
in the FCC photos, that J255 is populated
<dwfreed>
that screw is like right in the way, though
<stintel>
there seem to be pads for 4 more antennas
<dwfreed>
heh
<stintel>
maybe they're working on a 3-band version
<stintel>
so the J255 is actually a connector kind of thing
<stintel>
I guess I should find one of those - the pads seem big enough for me to pull off soldering
<dwfreed>
you probably just need to airgun it
<stintel>
wouldn't that melt the plastic of the connector ?
<dwfreed>
might :D
<stintel>
first I need to figure out what type of connector it actually is anyway :P
<dwfreed>
check the fcc photos
<stintel>
I am, but I don't recognize it
<stintel>
I'm not too familiar with all this stuff really
<dwfreed>
pinout is bottom pin is TP13, then progresses upward the same
<dwfreed>
with your closeup photo at 500% zoom, I can see the traces
<stintel>
yeah I believe I mentioned that earlier ;)
<stintel>
ugh I could try soldering wire to TP13 - TP15
<dwfreed>
tacking a wire to the TP pads would be safer, yeah
<dwfreed>
much bigger
Misanthropos has joined #openwrt-devel
<stintel>
looks like I might need to bridge a few pads too
<stintel>
T11 T12 T13
<dwfreed>
probably just 11 and 12
<dwfreed>
13 should be the voltage ref
<stintel>
yeah so TP13 seems connected to T11, TP14 to T12 and TP16 to T13
<stintel>
ugh I should have ordered some of those SMD resistors
aiyion has joined #openwrt-devel
<stintel>
I tried bridging some pads on an OC200 a while ago and ended up messing up the pads :P
<dwfreed>
too much jpeg in the fcc photos for me to see what they did
<stintel>
maybe I'll try finalizing ECS4100-12PH support first
<stintel>
don't have SMD resistors anyway
<aparcar>
robimarko: I think you can manually define the package suffix, so you can keep libdefalte on git base but make it use tar.gz, while the rest uses xz
<robimarko>
aparcar: thing is that there is no point in fetching libdeflate from git then
<robimarko>
Currently it was done so because XZ was built first
<f00b4r0>
stintel: really hard to tell from the pic but the resistors seems to be populated, aren't they?
<robimarko>
And then it could be unpacked in order to be able to unpack gzipped archives
<stintel>
f00b4r0: T11 T12 T13 not populated, the FCC photo does at least seem to have something on T11 and T12
<f00b4r0>
these aren't resistors. I'd expect diodes despite the T prefix
<f00b4r0>
they're likely ESD devices
<f00b4r0>
so most likely you can ignore them if they are wired the usual way (shunt to rails)
* f00b4r0
lookups FCC
<stintel>
well I'm not getting anything if I connect RX to TP14
<stintel>
so I suspect something is missing
<f00b4r0>
T == Transil, most likely
<aparcar>
robimarko: okay just wanted to let you know that you could use .tar.gz but I see your point
* f00b4r0
checks FCC pdf
<f00b4r0>
can't see squat
<f00b4r0>
stintel: if my assumption is correct, you're likely to find either GND or +VCC on either side of some of these pads, might want to check that before bridging anything :)
<f00b4r0>
(some of these Txx pads)
<f00b4r0>
the silkscreen symbol is definitely that of a diode
<stintel>
T13 pad on the left side (thin line) is connected to GND
<stintel>
and right side (thick line) is connected to TP16 which I suspect is VCC if it follows usual TP-Link layout
<stintel>
so definitely don't bridge T13 :D
<f00b4r0>
that ;)
<stintel>
looks like I'm going to the local hacker lab
<aparcar>
Mangix: nbd did you ever managed to build libxml2 on macOS?
<nbd>
yep, that's why the host build dep is needed
<aparcar>
i installed libiconv via homebrew and added it to my envs, but can't seem to find it
<nbd>
will add it
<aparcar>
great thank you
<nbd>
done
<aparcar>
does work indeed
<aparcar>
amazing RTT
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #openwrt-devel
<stintel>
anyone familiar with realtek target around? is there a reason non of the devices use FIT images (e.g. realtek u-boot doesn't support / enable it?) or is it an oversight?
<aparcar>
ynezz: I see your comments and will rework it, wasn't aware of this corner case
<stintel>
looks like the ECS4100-12PH u-boot does not like the initramfs image, suspect it got too big, I'm reading something about 6MB in commit message of other realtek device
<mrkiko>
robimarko: regarding the nbg7815: how are the two 5 gGHZ PHYs supposed to be used? How are they used in the stock firmware ? I ask because I did read this comment on the device topic - https://forum.openwrt.org/t/openwrt-support-for-armor-g5-nbg7815/98598/798 and, in case, wondering if some day athk11 might implements this. Are the two PHYs supposed to use the same frequency? Any pointer on the
<mrkiko>
topic? Thanks a lot.
<robimarko>
mrkiko: So it registers 2 5GHz WIPHY-s?
<robimarko>
AFAIK that was the "8x8" in QSDK
mattsm has joined #openwrt-devel
<mrkiko>
robimarko: yes, it registers 2 but I had some difficulties bringing up the second one
<mrkiko>
but yes you end up with a 2.4 ghz phy and 2 5 ghz one
<mrkiko>
robimarko: wondering if one day this might be supported or never... not holding my breath, just curiosity
<robimarko>
mrkiko: Sadly, I dont know how its supposed to work
<robimarko>
but I have a feeling that it doesnt really work as a standalone one
<mrkiko>
robimarko: I imagined it could work on same frequency with a sort of synchronization or coexistence scheme or whatever. I was thinking at first glance they could use different channels but the second phy doesn't look like you can use it straight away
hanetzer has joined #openwrt-devel
philipp64 has left #openwrt-devel [#openwrt-devel]
<stintel>
svanheule: ping
<svanheule>
stintel: o/
<stintel>
thanks for the review!
<stintel>
the setenv command is a remnant, shouldn't be needed (afaict)
<svanheule>
that's good! 4MB is really small...
<stintel>
yeah
<stintel>
I had trouble booting >7MB initramfs but that was because I didn't use what I wrote in the commit message *facepalm*
<stintel>
tftpboot 0x8f000000 is fine for a larger image it seems
<svanheule>
happens to the best of us :P
<svanheule>
nice, then this device has some years of support ahead of it :)
<svanheule>
that's to say... if we can manage to keep doing those kernel bumps on realtek
<svanheule>
if that's one of the external GPIOs, that might be due to a chip reset
<stintel>
also that commit message is from 2 years ago, man I have no idea where I got that info (maybe from the TIP wiki)
<svanheule>
people have mentioned the reset-at-boot behaviour before, but nobody really dug into it IIRC
<stintel>
[ 0.505472] RTL839X Chip-Info: a0036290, version D
<robimarko>
svanheule: any hope for 6.1 on realtek?
<svanheule>
stintel: doesn't is also print the full rtl839.. part number somewhere in the boot log?
<stintel>
[ 0.000000] RTL839X model is 83936806 ?
<svanheule>
stintel: that's the one! so it also says 8393 there
<stintel>
yep. on both units (I only opened and removed heatsink on one but both say 8393
<svanheule>
robimarko: there's more downstream driver code than combined developer energy to keep things moving :(
<stintel>
and someone ragequitting didn't help I guess :(
<svanheule>
stintel: 8392 is the less powerfull chip, so the "lowest common denominator" in a way. But you have actual HW with 8393, so I have a *slight* preference toward using 93 in the filename etc.
<svanheule>
stintel: certainly not :-/
<stintel>
alright, I have ~2 weeks before I'd like to start using the 2 units I have so I should have some time to sort some things out :)
<svanheule>
bmork has looked into 6.1 most recently, but he ran into an(other) vague issue with the VLAN dehavior
<stintel>
was the dedicated IRC channel still active ?
<robimarko>
Well, considering the giant pile of wonderfull magic code it would be weird if bumping kernels was easy
<svanheule>
the IRC channel is still present, but inactive
<stintel>
ok so not much point in joining I guess
<svanheule>
there's 10 users silently hanging out there :P
<stintel>
also I don't remember if these units came with OpenWiFi from factory or with some other thing, in any case I don't have access to "vendor interface"
<svanheule>
robimarko: I would love to strip some of the "extras" like L3 offloading to make thing more maintainable. Problem is that *also* takes time and energy
<svanheule>
stintel: vendor FW is usually based on the SDK and only works with initramfs images (and strips the squashfs trailer of a sysupgrade image)
<stintel>
if I plug in an SFP and try again -> reboot
<stintel>
Verifying Checksum ... Bad Data CRC
<stintel>
ERROR: can't get kernel image!
<stintel>
argh
<stintel>
so I *do* need that setenv thing
<stintel>
the 4MiB might be an arbitary chosen value because the default wasn't big enough
<stintel>
I guess I could experiment with bloating the kernel and see where it says no
<mrkiko>
I am a little bt confused - when we talk about devices like the fritz!box 5590 that have a fiber modem - does it mean you can use them without an ONT ? Or am I off?
<svanheule>
stintel: bloating an initramfs image might be easier
<stintel>
right, both use bootm so I guess it has the same limitations
<stintel>
bootm seemed to work fine with a ~7.2MB image
<stintel>
funny how they fake the 8392 in u-boot :P
<stintel>
so I commented out the gpio-restart part in the DTS, and the thing still reboots fine, does that mean I don't need the gpio-restart at all? it's not really clear to me tbh
<svanheule>
There are multiple reboot handlers available
<svanheule>
By default it will use the built-in watchdog
<svanheule>
But that's not really reliable on rtl838x