sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
nerozero has joined #openocd
tomtastic has quit [Ping timeout: 240 seconds]
tomtastic has joined #openocd
tomtastic has quit [Ping timeout: 240 seconds]
Haohmaru has joined #openocd
<Xogium>
borneoa_: if you ever get the chance… can you suggest st changes wifi chip on the mp1 dev kit ? :p only half joking… the brcm one they picked is pure yecch. Ok, all brcm stuff is meh far as I'm concerned… but I keep getting disconnected of my wifi no matter what I do, even disabling powersaving didn't help
<Xogium>
that kind of compromise the use for the board
<Xogium>
all I get for my trouble is this
<Xogium>
Jan 24 10:08:45 Tsenahale iwd[443]: Received Deauthentication event, reason: 0, from_ap: false
<Xogium>
yeah, that's not helpful at all
<borneoa_>
Xogium: not that much that I can do there. And by the way I have not used the onboard wifi yet, but I've eared only about speed issues so far. ST has a community forum where this kind of issue get logged and tracked and, when possible, solved. https://community.st.com/ from a quick search I don't see any such complain so it could be good to post it there. Same issue with ST image?
<Xogium>
borneoa_: hmm I'll check. But… yeah the st community forum isn't really usable when you're blind :/ accessibility is kind of lacking. Plus, I think only companies can register ?
<Xogium>
could it be because I use iwd not wpa_supplicant ?
<Xogium>
I'l try the st image again. At least I use no mainline component to boot which makes sure this isn't a problem that could be found only in mainline
<Xogium>
at least it doesn't take much time to reproduce this
<Xogium>
I only wait a few minutes and boom
<Xogium>
sometimes it reconnect on its own, sometimes it doesn't and I have to restart the AP or iwd
<Xogium>
will try st image now
<PaulFertser>
I just wanted to ask why iwd is supposed to be any better than wpa_supplicant for the task.
<Xogium>
its also kinda confusing which driver we're supposed to use given there is brcmfmac43430-sdio.bin but also a cypress driver
<PaulFertser>
wpa_supplicant can be run with -ddd and that might give some insight into what's happening.
<borneoa_>
Xogium: the community is for individuals. The target is really to have a community of people to share ideas. It works already quite well for MCUs, it's growing for MPUs.
<PaulFertser>
That bin file is firmware that is uploaded to the card itself.
<Xogium>
PaulFertser: iwd has integrated network management along with wifi handling, aka you don't need another chp client or network manager to get an ip and such, and it consumes less ram than wpa_supplicant+networkmanager or similar
<Xogium>
kinda why I picked it
<Xogium>
er dhcp client sorry
<Xogium>
but sometimes iwd or wpa_supplicant can behave differently so why I wondered
<PaulFertser>
Xogium: I do not think integrating a dhcp client in supplicant is smart. Also, wpa_supplicant calls appropriate action scripts on connection and disconnection so you do not really need a network manager of any kind with it as well.
<Xogium>
well, you can choose to enable that or not
<borneoa_>
Xogium: not really knowledgeable but I remember cypress chip was acquired by Broadcom, or the other way around. And the module is from Murata, that provides the firmware on GitHub. There is also one special config file in ST image used/loaded by the kernel module
<Xogium>
but 2 MB of ram used for a full network manager + wifi handler seems rather nice
<PaulFertser>
Cypress bought broadcom I think.
<Xogium>
borneoa_: yeah… I saw the brcm43430-sdio stuff, the hcd file that is used for bluetooth. But the st image carries both the cypress firmware and the brcmfmac firmware for the same chip ? Not sure if they are different
<PaulFertser>
dmesg is showing which one it loads
<Xogium>
hmm let me check
<Xogium>
ah, brcmfmac it is. Ok, so I had it good on my system also, for that part
<Xogium>
also +1 on ifconfig, that thing has been deprecated for quite a while now…
<borneoa_>
Xogium: should be BCM43430A1.hcd
<Xogium>
yep, indeed that's the one I copied, for bluetooth
<Xogium>
now waiting to see if the st image will decide to drop off from the wifi
<Xogium>
I can log into the ssh of my AP and check the logs also, and I see that the connection between my dev kit and the AP simply ends up timing out, then drops off
<Xogium>
but for all I know it could be because of one setting or another of my AP, some of those brcm chips are picky
Steffann has quit [Ping timeout: 256 seconds]
Hypercube3D_ has joined #openocd
Steffanx has joined #openocd
<PaulFertser>
borneoa_: ifconfig isn't just bad because it uses old IOCTLs instead of netlink interface but also it doesn't show all the addresses on the interface so that can get confusing. The syntax to specify mask is also more potentially confusing than a regular CIDR notation.
<Xogium>
that too
<karlp>
there's two binary blobs, one for wifi fw and one for bt firmware,
<karlp>
then there's also often a config text file for the bt
<karlp>
you can work on them independently though
<Xogium>
good to know. I didn't actually check the .txt I suspect it is better if I don't mess about in there ;)
<Xogium>
there we go
<Xogium>
Received Deauthentication event, reason: 0, from_ap: false
<Xogium>
wlan0: Lost carrier
<Xogium>
No network connectivity, watching for changes.
<Xogium>
damn
<PaulFertser>
Xogium: what are your AP settings btw? What band, what kind of encryption?
<Xogium>
PaulFertser: 2.4 ghz band, 20 mhz bw, wpa passphrase. I think wpa2 or 3 ? I always forget
<Xogium>
PaulFertser: this is a wifi 6 AP from ubiquiti that handles both 2.4 ghz and 5 ghz
<PaulFertser>
Xogium: wpa3 might be problematic. In fact, I've recently tried to understand how to use WPA3 (or at least PMF/MFP) with an SDIO module from broadcrap used on pinebook pro, and the answer wasn't encouraging. There're several firmware versions, some do not support it, some are just buggy like what you describe, and lose the connection at random intervals.
<Xogium>
I even disabled powersaving to make sure it wasn't coming from there
<Xogium>
oh, great
<Xogium>
I'll just go and see which wpa version it uses, I figure…
<Xogium>
so you did get random reason=0 too ?
<PaulFertser>
I didn't, I was just reading about pinebook pro.
<PaulFertser>
Xogium: but the latest firmware that supports wpa3 is unstable like you describe.
<PaulFertser>
That's for a different chip though, and I have no idea how similar they all are.
<Xogium>
ah
<Xogium>
well, anything is worth a try at this point, I'd say
<PaulFertser>
Xogium: you know it can do 2.5GBASE-T with OpenWrt now?
<Xogium>
nop, didn,t know
<PaulFertser>
If it's UniFi 6 LR
<karlp>
thos "config files" are more like binary patches sometimes paul, so yeah, they can be way more destructive/productive than you'd think :)
<PaulFertser>
karlp: if I get a pinebook pro I'll have to solder to 0.65 mm pitched pins of a USB hub inside to attach a proper wireless device instead of that broadcrap...
<Xogium>
hmm
<Xogium>
can't hurt to try that murata fw… I just need to also find the proper clm blob for it
<xantoz>
PaulFertser: you could attach one to PCI-E with the M.2 adapter
<PaulFertser>
xantoz: with a special adapter that's not sold anywhere yet?
<xantoz>
they've been selling it all along, although early versions had some clearance issues with the trackpad (I believe this has been fixed)
<xantoz>
I've used one to connect an NVMe drive to it (which I ultimately deemed to be too power-hungry to be worth it)
<PaulFertser>
xantoz: no, they were selling the one for NVMe.
<xantoz>
yeah. why wouldn't that work for M.2 wifi cards as well?
<xantoz>
it's PCI-E all the same
<PaulFertser>
xantoz: different pinout. I've checked where the PCIe lanes are routed to on M.2 for wireless cards. It's different because it includes USB.
<xantoz>
ah. I guess that might be the case. But is it for all wifi cards?
<PaulFertser>
Both clocks and lanes.
<PaulFertser>
xantoz: I do not think there're any wifi cards sold compatible to NVMe M.2 pinout, judging by the notches.
<xantoz>
I haven't actually looked that close. I thought it was primarily WWAN cards that used USB
<borneoa_>
Xogium: I've turned on my STM32MP157F-DK2 with wifi and pinged -f 8.8.8.8 for 2600 seconds. Did not disconnected from my Netgear.
<Xogium>
borneoa_: damn… I guess it just doesn't like my ubiquiti AP
<Xogium>
borneoa_: how did you connect, wpa supplicant ?
<borneoa_>
Xogium: yes, using the process in the wiki
<borneoa_>
Xogium: I have added in wpa..conf also key_mgmt=WPA-PSK taken from my PC config. I remember it took me mad in the past but now I don't recall the details
<Xogium>
alright then… we did the same thing
<Xogium>
the only thing is that I configured using wpa_cli
<PaulFertser>
Xogium: are you using it with ubnt firmware or OpenWrt?
<Xogium>
PaulFertser: ubnt so far. Frankly I've only had trouble with broadcom devices
<Xogium>
in fact the thing ran so well I didn't feel any need to switch to wrt ;) none of my other devices have problems, from tablet to phone to pc
<Xogium>
but all the boards that have boradcom ? They all go nut with this AP it feels like
<Xogium>
ok just for the hell of it I'll restart both my AP and the board
<Xogium>
borneoa_: yeah ok this is just getting more and more insane. I had yet another kernel oops
<PaulFertser>
Xogium: that's an interesting trace you have there
<PaulFertser>
Xogium: probably hinting at issues in ST hw crypto driver rather than the wifi problems.
<PaulFertser>
Xogium: have you tried disabling stm32_cryp altogether?
<PaulFertser>
Xogium: probably not having it as part of the build.
<Xogium>
PaulFertser: no, must admit that did not cross my mind. I mean, I figured it was good to use and wouldn't cause any issue seeing that yocto image has it enabled too. But I could try that on my own build, for sure
<Xogium>
btw that was an oops using the yocto image. I can hit the same one at random on my image if I use wpa2/wpa3 mode, and seemingly on purpose if I set to wpa2 only
<PaulFertser>
Xogium: worth a try
<Xogium>
yeah sorry for the topic here, I know it's openocd but given that the st community isn't very usable I honestly have nowhere else to ask, borneoa_ being the only person I know works for st ;)
<Xogium>
I wasn't able to read the whole of that oops but to me whatever it is, appears to explode because it tries to use what is clarly an invalid memory address, unless I'm dumb
<Xogium>
that's the null pointer dereference which then causes an oops, from… I guess like you say, possibly the stm32_crypto
<PaulFertser>
Yes
<Xogium>
hmmm I didn't know that
<Xogium>
if it uh stops crashing on wpa2, so then behaves fine
<Xogium>
that would be a compromise I can live with
<Xogium>
though… I'd assume st patched these in their own kernel first ?
<Xogium>
still, I'll disable it here, and see if it blows up still
<Xogium>
I suppose I could also blacklist it from the yocto image ?
<Xogium>
would blacklist be enough so it doesn't get loaded at all ?
<PaulFertser>
Xogium: depends on whether it's compiled as a module or linked in.
<Xogium>
lets see
<Xogium>
it is definitely a module
<PaulFertser>
Try to unload it then. And blacklist for good measure.
<PaulFertser>
Better to reboot and make sure it's not loaded.
<Xogium>
yep doing that
<Xogium>
alright there we go not loaded. Lets try and make it go boom
<Xogium>
hmmmm
<Xogium>
I've noticed that somehow wpa_supplicant and iwd don't connect the same way to a network
<Xogium>
iwd tries to use in kernel crypto modules either software or hardware like that stm32_cryp criver
<PaulFertser>
Might be
<Xogium>
in fact blacklisting it now makes iwd fail because it cannot find any suitable crypto driver
<PaulFertser>
Should be in-kernel software fallback available too.
<Xogium>
PaulFertser: well not sure. There is no fallback on the st kernel in yocto, that much I can say
<Xogium>
it doesn't want to run iwd anymore, whyle wpa_supplicant runs fine
<PaulFertser>
Xogium: probably the needed options are simply not enabled.
<Xogium>
yeah that is it. But then how come wpa_supplicant has no issue running, does it not rely on this ?
<PaulFertser>
I think it doesn't use in-kernel crypto, yes.
<Xogium>
alright let me try wpa_supplicant again for the last time and see how long it lasts :p
<Xogium>
just so we're clear on that the oops is actually seemingly 100% reproducible every time I try and use iwd with stm32_cryp driver. So that one at least is no longer a concern in this current problem of wifi
<Xogium>
but it might be good if it was reported
<Xogium>
100% reproducible on wpa2 mind you
<PaulFertser>
Xogium: you can even tell which source code line is causing the oops, using addr2line and the address in PC.
<Xogium>
PaulFertser: addr2line ? I didn't hear of that
<Xogium>
PaulFertser: how do you use that exactly ? Like you make the system cause an oops, the you give it the pc memory address ?
<PaulFertser>
Xogium: yes, in your paste there's "PC is at stm32_cryp_finish_req+0x220/0x33c".
<PaulFertser>
Xogium: means it's 0x220 bytes into that function.
<Xogium>
oooh
<Xogium>
makes sense
<Xogium>
well for now I'm going to switch my own system to wpa_supplicant since iwd is definitely nowhere near suitable here given this bug
<Xogium>
but yeah need to figure out the reason=0 thingy too
<jancoow>
Best way to communicate to openocd from a python script?
<PaulFertser>
jancoow: RPC
<PaulFertser>
jancoow: there's an example in python in contrib
<borneoa_>
Xogium: sorry, I was offline for some time. It could be relevant to submit the report of the crash in ST forum. Or you could contact directly Nicolas the submitter of the patch. I can also report it, but a direct link with you would be more effective.
<jancoow>
Over the tcl port?
<jancoow>
Where is an example?
<PaulFertser>
borneoa_: ST forums are awful even for a sighted. All that JS... And when Xogium says they're not really accessible to a blind person I'm sure he means it.
<PaulFertser>
jancoow: contrib/rpc_examples/
<jancoow>
I'm not sure where you are seeing that
<PaulFertser>
jancoow: in OpenOCD source tree
<Xogium>
borneoa_: yeah… I understand. Maybe something by email could be arranged ?
<jancoow>
I see thanks
<borneoa_>
Xogium: by email could work. I don't know exactly what Nicolas has fixed, and your use case could be relevant
<Xogium>
borneoa_: but I'm pretty sure you could also replicate the bug. For me at least all I needed was a wifi network configured with wpa2 security, then used iwd: iwctl then type station wlan0 connect yourssid, fill in the passphrase and BOOM
<borneoa_>
PaulFertser: yes, full of JS.
<Xogium>
you can also use tab completion int iwctl prompt
<PaulFertser>
They were better before
<PaulFertser>
But now one can't even read them without JS.
<Xogium>
again this is on st kernel… So I assume he pushed fixes to the st kernel before submitting them to mainline ?
<Xogium>
but who knows
<Xogium>
harder to reproduce when the network is configured in wpa2/wpa3 mode, but still manageable. I am not sure if the issue is related to the security used, but wpa2 only has a better chance at hitting it since I've hit it about 7 times that way
<borneoa_>
Xogium: I see that Nicolas patches are already part of yocto build for 5.10.61, but upstreamed later. Did you reproduce the ops with ST kernel too?
<Xogium>
borneoa_: yes the log I pasted is straight from the yocto image
<Xogium>
the latest image
Haohmaru has quit []
Hypercube3D has joined #openocd
Hypercube3D_ has joined #openocd
<jancoow>
PaulFertser mhh after starting openocd I see as command response target information; like " 4 hardware breakpoints" etc
<jancoow>
This is just information openocd sends on startup, not really the actual command response
<jancoow>
Why is this?
<PaulFertser>
jancoow: you see it return on RPC port?
<jancoow>
I'm not at my pc currently but yes that is what happened
<PaulFertser>
jancoow: but RPC doesn't have unsolicited responses so some prior command should have been sent to it?
<jancoow>
Mh
<jancoow>
I don't have a target/debugger ATM but can I test it without it?
<PaulFertser>
Not sure. Have you tested the example from contrib, did it not work?
<jancoow>
Not directly that example but that is basically what I implemented
<jancoow>
Send and wait for that character
<PaulFertser>
I suggest next time you have a target handy you try the example as is (an example matching your openocd version).
<PaulFertser>
Hard to discuss it meaningfully without seeing debug logs etc.
<jancoow>
I was just curious
<jancoow>
I don't see any errors like error: target not halted
<jancoow>
Or any other errors
Bertl is now known as Bertl_oO
<jancoow>
So it's hard to write a solid communication
<jancoow>
Mhh, do I need to use capture for that?
<PaulFertser>
jancoow: capture means capture everything that OpenOCD prints after starting to execute your command. It's not just the command return value you get then if you're using capture.
<jancoow>
Okay, currently not using capture
Hypercube3D__ has joined #openocd
Hypercube3D has quit [Read error: Connection reset by peer]
Krazubu has joined #openocd
<jancoow>
We are trying to use it for a programming station but to get to have openocd communication good is quite hard
<jancoow>
Especially when a target disconnected with letting openocd open
<PaulFertser>
jancoow: why are you not showing logs?
<jancoow>
I'm not at my pc at the moment
<PaulFertser>
jancoow: I hope we'll be able to sort it out when our communication becomes more interactive.
<jancoow>
Oh I was just general talking
<jancoow>
Curious how other people tackle this problem
<jancoow>
But might not use openocd for it idk
<PaulFertser>
Some people run openocd from a script, some talk to it over RPC.
<jancoow>
And restart every new programming cycle or left open?
<PaulFertser>
Restart would be easier, especially for a script.
<jancoow>
Not about easy; more about what works best
<jancoow>
Because how to tell openocd a target is going to detach
<PaulFertser>
Restart sounds like a more reliable way, as you have exactly the same state every time.
<PaulFertser>
If you're going to restart anyway you can just let openocd exit after it's done flashing.
<jancoow>
Mhh okay
<PaulFertser>
jancoow: OpenOCD has -c "program your.elf verify reset exit" for that.
<ampleyfly>
I wrote a fix for flash erase on STM32F42x/43x in dual bank mode, but the patch needs verification on some additional variants. Is anyone able and willing to test it on STM32F 76x/77x/469/479 (with 1MB flash)?
<PaulFertser>
ampleyfly: hey! Thank you. I suggest to send it to the review server, some nice fellows from ST will provide enough feedback.
<ampleyfly>
I did :)
<ampleyfly>
Just checking, because not much more than that conclusion has happened so far
<ampleyfly>
figured there might be some need of assistance
<PaulFertser>
ampleyfly: thank you, and I hope the review happens rather sooner than later.
Hypercube3D_ has quit [Quit: Leaving]
Hypercube3D__ has quit [Quit: Leaving]
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]