goliath has quit [Remote host closed the connection]
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #openwrt-devel
valku has quit [Quit: valku]
<damex>
any idea where i could find edgerouter poe-5 datasheet/schematics? my old one does not show any signs of life and after connecting it to 48v power supply - i get 8v right at the jack
<damex>
want to get openwrt running there. runs same cavium processor as edgerouter lite
guidosarducci_ has quit [Ping timeout: 480 seconds]
<mrnuke>
damex: the "backup" image is just another rootfs. The kernel doesn't have a redundancy. You won't be able to get to u-boot console without modifying the bootloader.
<damex>
mrnuke: so that sg2210p is doomed?
<mrnuke>
damex: not really. We just have to figure out why the bootloader is complaining
<damex>
> You won't be able to get to u-boot console without modifying the bootloader.
<damex>
so that thing, how is it supposed to be recovered at this point?
<mrnuke>
damex: You can try to extract the kernel from a vendor update image and flash that via TFTP, or try to flash that -sysupgrade image over tftp
<damex>
mrnuke: well, device had to be turned off and it does not come up now. no ethernet lights up after any amount of time. how do i extract 'kernel' from vendor image to try to serve it over tftp?
<damex>
mrnuke: i tried flashing -sysupgrade image over tftp and you know how it turned out :)
<mrnuke>
It's been a while since I messed with those TP-Link switches
<damex>
mrnuke: so decrypt -> extract -> copy uimage.img to tftp root and that's it? is there a way to trigger recovery?
<mrnuke>
damex: I remember getting the device stuck in a mode where it wouldn't recover from a bad kernel. The shorting out the CLK pin was the only way to get it out of that mode and trigger recovery
<damex>
mrnuke: power it up with shorted clk pin?
<damex>
and disconnect 1s later?
<mrnuke>
short it out as it's loading the kernel. That uses the standard u-boto codebase. if you short the ping as it's loading the the uimage header, then it should trigger recovery
<damex>
mrnuke: how do i know it is loading kernel? i tried shorting it moment after supplying power, after 1s, after 2s and etc.
<damex>
there is no serial output available so there is that
rua has joined #openwrt-devel
<damex>
i wonder why they tie uboot serial to that properly working kernel >_>
<damex>
whole purpose of having uboot access in that case would be to recover
<mrnuke>
They modified u-boot to put their (TP-Link's) own serial interface, called BOOTUTIL. That's used on some higher end switches with an actual serial port. I presume they don't want users getting to a uboot shell and "accidentally" erasing important flash sections
<mrnuke>
BOOTUTIL isn't very useful on switches without a serial port header
<damex>
mrnuke: can't one replace with something more sensible?
<mrnuke>
BTW, make sure you check both 38400, and 115200 baud rates. It's possible to change the baudrate by editing the u-boot env
Borromini has joined #openwrt-devel
<damex>
i did check, my serial adapter lights up when something comes up even if i don't get proper rate :)
<mrnuke>
damex: I modified the bootloader on one of my switches to drop me to a uboot shell. It's doable, but a major pain in the arse, and requires desoldering and extermal programmer
<damex>
mrnuke: hm... can't we do it in software since official package bundle uboot+rootfs+kernel+other random stuff?
<damex>
i mean... atleast once :D
<damex>
before you would actually need an external programmer
<damex>
well, i do have ch341a and other stuff but... i'd rather not. and no soic16 clip yet.
<mrnuke>
Don't bother with external programmer unless you're willing to solder an SOIC socket. Reason: the reset circuit might drive your ROM in reset, and you nuts
<mrnuke>
as far as updating in software, you can after flashing openwrt. From vendor firmware, I don't have a way to SW flash
<damex>
mrnuke: argh... well, i didn't expected such resistance from sg2210p that's for sure
<damex>
mrnuke: any idea about what could be attempted to do next?
<mrnuke>
damex: speaking of resistance, make sure your resistor on the TX line sdin;t blow up. I had to replace one of those tiny resistors that had gone open circuit for no apparent reason
<mrnuke>
One of three things: (1) try different baudrates. (2) Double-check continuity form the SOC to the UART headers, and (3) Decrypt and compare the vendor images for 3.26 and your exact version. See if the uimage header is different
<damex>
mrnuke: on last sg2210p there is no pads or trace leading to tx pin. i have had to solder directly to 4.6kohm resistor side that is next to soc pins
<damex>
it worked just fine
<damex>
i wonder why we need 50ohm resistor next to gpio pins if rx and tx go through 4.6kohm resistors
<damex>
mrnuke: baud rates is not a problem - uart 'pins' are exposed correctly. problem is that it does not even try to load from tftp. i tried booting it with clk shorted, short it seconds after supplying power and etc. no difference
<mrnuke>
No idea. There were other 33 and 50 ohm resistors near pads, so I just chose that as a "reasonable" value
<damex>
mrnuke: usually on tplink you just bridge that pads
<mrnuke>
You can't short CLK on power on. The SOC needs to load u-boot from flash. You only short CLK as uboot is trying to load the kernel
<damex>
robimarko confirmed that it was like that for other tplink devices. i found the same on forums
<damex>
mrnuke: yeah, i tried to do it up to 10s after supplying power
<mrnuke>
A non-zero resistor gives you some short-circuit current limiting
<damex>
wait 1s -> short. wait 2s -> short and etc. no results up to 10s and 10s should be enough to read uboot
<mrnuke>
I'd expect to see at least the "Hit any key to stop autoboot" message on the UART
<mrnuke>
I need to re-check tomorrow how the thing behaves
<damex>
i use that round crappy clips from my logic analyzer connected together. one on clk and second touching ground when needed
<damex>
so that part is pretty consistent
rua1 has joined #openwrt-devel
<damex>
mrnuke: sadly i don't get any output
rua has quit [Ping timeout: 480 seconds]
<damex>
i wonder if there is other 'easy going' openwrt supported switches that wouldn't require hoops with soldering, shorting and praying to voodoo to get it working
csrf has joined #openwrt-devel
rua1 has quit []
chuck48 has joined #openwrt-devel
<Borromini>
damex: many of the ZyXELs
chuck48 has quit [Ping timeout: 480 seconds]
<mrnuke>
damex: I also wrote support for Engenius EWS-2910P. That can be updated from the vendor web interface
<mrnuke>
damex: I would check things systematically (on SG2210P)> Check the RESET, clk, and data pins on the ROM. Make sure that the RESET is being released, the SOC is requesting data from the ROM, and the ROM responds.
<mrnuke>
damex: If that doesn't happen, then I would suspect a hardware problem. Otherwise, software
<oliv3r[m]>
Anybody know which kconfig symbol I'm missing that triggers this error: Error: opcode not supported on this processor: mips32 (mips32) `ext
<oliv3r[m]>
(it worked in the past, so I know its something I did :p)
<hauke>
oliv3r[m]: you are probably missing the compiler option to compile for MIPS32r2
<oliv3r[m]>
so why did it work yesterday? :)
<oliv3r[m]>
i haven't changed my container. More importantly, how do I enable it!
<oliv3r[m]>
actually, if openwrt updates these kinds of dependencies, it will affect my container i'd think
<oliv3r[m]>
i'll wipe my builddir to see what happens
<oliv3r[m]>
ah wait, the compiler doesn't actually reside there, have to pull my container to update!
<oliv3r[m]>
still strange while this break even though I didn't touch the container, as it's been running for days/weeks.
<oliv3r[m]>
using the latest sdk container, though it's 2 months old; I think i was using a 6 month old one before; so doubt that'll make a difference ..
<Znevna>
only logical explanation, you've been hacked
aleksander has quit [Quit: Leaving]
<oliv3r[m]>
haha, yeah, the container must be hacked :)
<oliv3r[m]>
But not it gets worse, I threw away the container, pulled the sdk one; and now I get this: Error: opcode not supported on this processor: mips32 (mips32) `ext
<oliv3r[m]>
er, copy paste fail :) ../../build_dir/host/zstd-1.5.2/build/meson/meson.build:11:0: ERROR: Executables created by c compiler gcc are not runnable.
<oliv3r[m]>
really not what I wanted to mess with today
<oliv3r[m]>
frustratingly of course, all other packages are compiling just fine (-j8 :p)
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<robimarko>
vulpes2[m]: Hm, so U-boot has a stupid logic
<robimarko>
They check if DTS is present and if so then assume that pylibfdt should be as well
<robimarko>
Otherwise if DTC is not present they build it
dansan has joined #openwrt-devel
zorun has joined #openwrt-devel
<vulpes2[m]>
Force building dtc with the patch in uboot-mediatek worked but I had to build scripts/dtc/pylibfdt as well
floof58 is now known as Guest939
floof58 has joined #openwrt-devel
<robimarko>
I am not sure if dtc is one of the host tools that is used
<robimarko>
But its available for sure, what is not is pylibfdt
<robimarko>
Basically, the U-boot logic needs to not just check for dtc
<robimarko>
And then assume that pylibfdt is present
<robimarko>
Yes, but it wont trigger a build if not present
<robimarko>
It will only build dtc and pylibfdt is dtc is not present
<vulpes2[m]>
$(MAKE) $(build)=scripts/dtc doesn't seem to even build pylibfdt either, I had to explicitly tell it to do $(MAKE) $(build)=scripts/dtc/pylibfdt as well
<stintel>
I'm reverting to 5.10 for now which does not expose this problem and VPN tunnels going down multiple times per day while on holiday is ....
<stintel>
philipp64: fyi I also asked Thermi
<vulpes2[m]>
Since this is working now I'll just patch out the checks and force build pylibfdt + dtc for the moment like uboot-mediatek did. I can look into fixing this properly with the upstream in the future.
<robimarko>
Sounds like a plan
<vulpes2[m]>
hauke: what's your preferred approach to add swig to the build system? from what I can tell we can just install it on the host system instead of building it from source?
<robimarko>
It can be added as a prerequisite but a check for it needs to be added as well
<robimarko>
So it will just use the host one
<aiyion_>
I'm just looking over the patch to add support for the DAP-X1860, which does behave like the commit message suggests, extended test will follow tomorrow night, when I'm with the router again;
<aiyion_>
The wifi interfaces irritates me though.
<vulpes2[m]>
sure, let's just put swig in a prerequisite check then
<robimarko>
Does MacOS provide swig?
<robimarko>
Cause if not that would break support for it
<aiyion_>
"phyX-staY" spawns out of nowhere when one opens an accesspoint, while phyX does not appear until one does. Any ide, where I can read up on this supposedly new behaviour?