mrnuke has quit [Remote host closed the connection]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
matoro has quit [Ping timeout: 480 seconds]
matoro has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
torv_ has joined #openwrt-devel
torv has quit [Ping timeout: 480 seconds]
mrnuke has quit [Remote host closed the connection]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
bluew has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
srslypascal has joined #openwrt-devel
Slimey has quit [Remote host closed the connection]
srslypascal is now known as Guest5817
srslypascal has joined #openwrt-devel
Guest5817 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
valku has quit [Quit: valku]
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
SlimeyX has quit [Read error: Connection timed out]
SlimeyX has joined #openwrt-devel
ptudor_ has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
torv_ has quit [Remote host closed the connection]
torv_ has joined #openwrt-devel
danitool has joined #openwrt-devel
MaxSoniX has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
indy has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
indy has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Slimey has joined #openwrt-devel
danitool has joined #openwrt-devel
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
schwicht has joined #openwrt-devel
schwicht_ has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
<fpsusername[m]>
Harm_: Hey, I am trying to flash the patched bootloader, but I'm getting a mismatch error
<fpsusername[m]>
Even when I try flashing the original bootloader
<fpsusername[m]>
* patched bootloader (experia wifi), but
rua has quit [Quit: Leaving.]
<fpsusername[m]>
Oddly enough, now when I pull the file again, I get a different file from the original/first pull and the modified bl from the first pull
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
mrnuke_ has joined #openwrt-devel
mrnuke has quit [Ping timeout: 480 seconds]
<Harm_>
fpsusername[m]: sounds like a bad connection with the flash. Reading data should be consistent all the time
<Harm_>
Did you desolder the flash?
<fpsusername[m]>
Then the flash is screwed if the first read isn't good
<fpsusername[m]>
I didn't desolder the flash. Usually there's no problem with using a programming clip on an unpowered PCB
<Harm_>
Unless you also power the cpu with it
<fpsusername[m]>
I flashed EEPROM like that of a tachometer
<fpsusername[m]>
Have to wait a bit before I can download. Apparently the domain is blocked by one of the blocklists on nextdns
<Harm_>
fpsusername[m]: Well, I see your first pull is fine :). So you can continue with that one :)
<fpsusername[m]>
Downloaded
<fpsusername[m]>
Harm_: I patched it and flashed but well, mismatch.. Will try yours after dinner
<Harm_>
fpsusername[m]: yeah, your unknownbl version is corrupted in some places. So I suppose something goes wrong with writing data. I compared it via ` meld <(hexdump -C bootloader_original_unknownbl.bin) <(hexdump -C bootloader_original_first_pull.bin) `
<Harm_>
fpsusername[m]: You could try lowering the SPI clockfrequency. Maybe that helps
<fpsusername[m]>
<Harm_> "fpsusername: yeah, your unknownb..." <- I use 010editor
<fpsusername[m]>
<Harm_> "fpsusername: You could try..." <- Will try
<fpsusername[m]>
But how do I do that?
<Harm_>
fpsusername[m]: are you using my device tree overlay?
<fpsusername[m]>
Yes, the one you shared on tweakers
<fpsusername[m]>
So you are on 20Mhz, I'll reduce it to 4
<Harm_>
fpsusername[m]: yeah
<fpsusername[m]>
Best to add the -v flag on the flash command
<Harm_>
that should give a progress report
<fpsusername[m]>
Hmm no, same error at the same address
<fpsusername[m]>
Did you do something with the IC's reset pin?
<Harm_>
I left it unconnected
<Harm_>
You could try clocking even lower, flashing is quite slow and maybe it still reaches the same maximum speed at 4MHz
<fpsusername[m]>
Trying 400kHz
<fpsusername[m]>
I wonder if I could technically power the PCB and then overwrite with the pi
<fpsusername[m]>
Odd now it fails verification at the beginning
<fpsusername[m]>
5%
<fpsusername[m]>
I'll slow it down more
<fpsusername[m]>
The area near the IC does get warm, so it's definitely not a very stable method. Perhaps some circuitry doesn't like the voltage.
<fpsusername[m]>
Maybe voltage is dropped too much, I didn't verify that
<Harm_>
fpsusername[m]: so when you power the whole board, the CPU will start sending commands to the flash. Those signals will conflict with your signals
<fpsusername[m]>
Well, if the CPU is connected to the same voltage supply as the storage, then yes, perhaps
<Harm_>
fpsusername[m]: you could even try lowering the voltage, maybe you can find a point where the flash does get enough to start and the rest finds it too low to do anything
<fpsusername[m]>
So maybe I should erase the 48 blocks, then power up the board the normal way, wait a bit and flash
<fpsusername[m]>
Lowering voltage isn't possible with the rpi though. I'm not using a lab psu
<fpsusername[m]>
And if that won't work, I'll desolate it on Monday at work with the heat gun
<Harm_>
fpsusername[m]: it might work if you can let it idle in u-boot, e.g. at the password prompt. Though I'm not sure how much of that works with your corrupted u-boot
<Harm_>
Though SPI is push-pull right? So wouldn't you then connect the output pin of the cpu's MOSI with the output pin of the rasperry PI's MOSI, effectively creating a short circuit?
<fpsusername[m]>
400k is the lowest it'll go
<fpsusername[m]>
SPI doesn't have to be push pull. Do doesn't have to be connected
<fpsusername[m]>
Oh hear this. When I unpower the IC, it still fails at 5% verifying
<fpsusername[m]>
It should fail at erasing
<Harm_>
interesting
<fpsusername[m]>
Hmm, don't think it'll work
<fpsusername[m]>
I'll try to flash with do disconnected, then reread it and see if the content matches
<Harm_>
I found removing the chip with a heatgun the easiest. I've also tried adding a bit of tin to each pin of the chip, and while the tin is fluid i bent it a little to disconnect it from the PCB, then remove the extra tin again
<Harm_>
Depending on your patience (as you have the heatgun at work), you could try that method. I left the NC pins in place
<fpsusername[m]>
Yeah, I have the tools, heatgun, flux, everything
<fpsusername[m]>
Easier to remove the whole IC than trying to bend pins
<fpsusername[m]>
Besides that, wouldn't work well with bend pins
<Harm_>
Oh yeah, I forgot you were using that clip. That won't work well with bent pins indeed
<Harm_>
Mine will arrive in a few months
<fpsusername[m]>
Hmm, seems like it reads tons of garbage now
<fpsusername[m]>
Most of it is just erased
rua has quit [Ping timeout: 480 seconds]
<Harm_>
fpsusername[m]: looks like a lower clock made it worse, maybe increase the clock :P?
<fpsusername[m]>
Lets see what the max clock speed of the IC is
<Harm_>
iirc it's 50MHz
<fpsusername[m]>
The thing is, even after returning to 20MHz, it still reads 5% matching data
<Harm_>
Oh the 50MHz is when the 0x3h read data instruction is used. It can go higher (133)
<Harm_>
after flashing?
<fpsusername[m]>
50MHz at 03 indeed
<fpsusername[m]>
133 is likely for quad SPI mode
<fpsusername[m]>
Wait no
<fpsusername[m]>
133 is max for single SPI
<fpsusername[m]>
532MHz for quad spi
<fpsusername[m]>
So if the RPI 3B can do 133MHz
<fpsusername[m]>
I'll try
rua has joined #openwrt-devel
aiyion_ has quit [Remote host closed the connection]
<Harm_>
I'm no expert in this but 133 could require a better cabling
aiyion_ has joined #openwrt-devel
<Slimey>
slow and low
<Harm_>
Slimey: f~psusername is flashing in-circuit and using a slower speed seems to have made the quality worse
<Slimey>
really? usually its the other way around
<fpsusername[m]>
Hmm, maybe. Convert the MHz to the time scale, then check how much distance it will travel in the time of one pulse (electricity travels at ⅔ of the speed of light)
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openwrt-devel
<fpsusername[m]>
133 doesn't work (no connection). Back down to 50
<fpsusername[m]>
50 works, but data is still corrupted. 10k/192k (5%)
<jow>
the latter also offers a link to switch to the former now
<jow>
is that clearer?
<f00b4r0>
jow: the latter is, the former conflicts with my experiment yesterday
<jow>
conflict how?
<f00b4r0>
because the global import did not configure my wireguard interface as a _client_, it configured it exactly as described in the pasted wg.conf (which is the behaviour I expected): [Interface] became the (openwrt) interface setting and the attached [Peer] entries became peers in openwrt
<jow>
isn't that "as client" ?
<jow>
probably just a different interpretation of the same thing
<f00b4r0>
to me "as a client" implies that the configuration I paste will be processed to become a *peer* of the pasted server
<jow>
it's not actually a "client", I thought this term just makes it easier for people wanting to import their commercial vpn provider conf to establish a connection there
<jow>
in this case the system would be a client to that service
<jow>
and the conf you receive from the provider would be a "client config"
<f00b4r0>
in fact, in wireguard, "client" doesn't really make sense, I would simply say "drag or paste an existing wireguard *.conf file below to configure this system".
<jow>
I know that
<jow>
but casual users don't
<f00b4r0>
well if I get this right, your wording assumes that casual users will copy/paste a tunnel provider "peer" configuration, as in the provider will cook up a complete config for a remote peer
<jow>
also wonder how often people will have a preexisting wg0.conf they want to import into openwrt
<jow>
can only think of either a) they want to connect openwrt somewhere else and got handed that wg0.conf from the server operator
<jow>
or b) want to migrate an existing setup to openwrt
<jow>
my guess is that a) is way more common
<f00b4r0>
that's one use for this import, but it's also perfectly valid to e.g. generate a number of wireguard configs programmatically for multiple routers to talk to each others (and eventually bridge their respective lans, which is, incidentally, exactly what I'm doing :)
<jow>
f00b4r0: correct, a prover will generate a complete wg0.conf
<jow>
including privkey, and a [peer] section containing the providers server
<jow>
plus allowedips, potentially psk etc.
<jow>
s/prover/provider/
<f00b4r0>
I wouldn't assume that a) is more common, and the more generic wording I suggested works for all cases
<f00b4r0>
the providers you have in mind will be all too happy to leverage this import in their howtos :)
<f00b4r0>
they will guide the "casual users" as needed there. No need to assume all OpenWRT users are the type that will use a wireguard tunnel provider (at least IMHO)
<jow>
judging fro mthe various wireguard related support topics in the forum and the bug reports I got it almost always seemed to be about connecting to a service
<f00b4r0>
this could be a forum bias, where this particular type of user may either a) have more difficulties or b) be more vocal (or both). Again, I see no harm in being less "prodding"?
<fpsusername[m]>
<Harm_> "Slimey: f~psusername is flashing..." <- Cpu is definitely being powered. 2 leds are constantly on. Flashing an empty bootloader is a success. Flashing back any bl with 20mhz is fail at 62%
<jow>
fine with me
<jow>
what term fits better? "existing" or "supplied" config?
<f00b4r0>
and honestly with the wording you propose, reading it would completely deter me from using it the way I did and I suspect I wouldn't be alone reacting this way
<f00b4r0>
jow: how about "Drag or paste a valid WireGuard *.conf file below to configure this system"? ;-)
<f00b4r0>
even less assumptions, but one important addition ("valid") :)
<jow>
ok
<f00b4r0>
👍
<jow>
I'll just use that to finally get this done. Shouldn't have opened that can of worms
<f00b4r0>
haha
<f00b4r0>
well thanks for seriously improving the situation anyway!
<f00b4r0>
jow: btw, shouldn't it be "this interface" even?
<f00b4r0>
since there may be others
<f00b4r0>
(I never tried that but it should be possible)