<gamiee>
PeulFertser: It was indeed helpful. I might ask some more questions in future, as I would like to make flash driver, so OpenOCD can directly write firmware into flash.
<gamiee>
Although, I have some more questions, less "RISC-V" related.
vampirefrog has joined #openocd
<gamiee>
1) How to deal with run in RAM scenarios? When debugging in-Flash firmwares, it is expected to "reset board and halt, write stuff to flash, reset board again and run". In terms of RAM firmware, it should be just "write into SRAM and run". Thankfully, both RAM and TCM are working out of the box, no init required, but still, before running, ideally I would like to keep bootrom init sequence to finish, and then jump into RAM. How this should be done?
<gamiee>
2) Why companies like Espressif or STM does not upstream the patches (only some of them?). Are there some challenges I should be aware before trying to upstream stuff?
MGF_Fabio has joined #openocd
<PaulFertser>
gamiee: I think it should be "reset halt", write to RAM, set PC and SP register and "resume".
<PaulFertser>
ST upstreams their patches, and many other companies too.
<PaulFertser>
Nothing special about it. The review process is slow though as not many people participate, unfortunately.
<gamiee>
PaulFertser: ah okay. This set PC and SP register should be done in custom tcl script specific to project, am I right?
<gamiee>
About upstreaming, of course they do, but I noticed that for example, STM doesn't pushed their STM32U5 support (it's only in the fork), and Espressif did not pushed their RISC-V chips support.
<PaulFertser>
gamiee: yes, there're no generic means for debugging in RAM. When you do "load" in GDB with an ELF then PC is set automatically by GDB to the entry point but I'm afraid not SP.
<PaulFertser>
Probably U5 support isn't really good quality yet.
Haohmaru has joined #openocd
<gamiee>
PaulFertser : OK, makes sense! GDB doesn't set SP, but that's okay. I am mostly worried about some low-level init which bootrom does, but it is not that "mandatory"
<gamiee>
About U5, it works. About Espressif, their RISC-V stuff seems to work too. That's why I am asking, as I am surprised it's not upstreamed.
<gamiee>
Also, I wonder why there is RISC-V fork of OpenOCD? I didn't found anywhere mentioned what are differences between them, but it seems that it contains more support for RISC-V, and also they keeping synced with upstream openocd.
joconor_ has joined #openocd
_olerem has joined #openocd
joconor has quit [Ping timeout: 268 seconds]
mark_feathers has quit [Remote host closed the connection]
olerem has quit [Ping timeout: 268 seconds]
mark_feathers has joined #openocd
<PaulFertser>
gamiee: sometimes vendors offer instructions about how to let BootROM run to the right spot. It might be a variable in memory or breakpoint or watchpoint on specific address.
<PaulFertser>
The fork is getting upstreamed slowly, just it's more experimental in nature and some changes from it were controversial.
<gamiee>
until upstream will work for me, I will use it.
<gamiee>
PaulFertser : this sounds interesting, do you know please about target tcl script which does this, so I can inspire from it please?
<gamiee>
(also, about the fact that GPIO stuff are not reset on software reset, it makes sense, the RESET registers are on GLB peripheral, which also control GPIOs. If GLB is reset, pinmux is reset too, so JTAG connection will be lost, since bootrom configures pinmux for jtag)
<gamiee>
Solution for this is upload instructions into work area to perform GLB reset and then main reset, so even when we lost JTAG connection, chip is reset.
<PaulFertser>
btw, you can see I added support for a new part but nobody can review it so it's sitting there unmerged...
<Haohmaru>
does openocd have a leading developer?
<gamiee>
PaulFertser : oh no :( that's quite concerning.
<PaulFertser>
This MCU is not that popullar.
<gamiee>
but that should not be a reason for not merging it, or?
<PaulFertser>
I'm not sure, the code I wrote is kind of dirty
<Haohmaru>
which MCU?
<PaulFertser>
Haohmaru: lpc55
<Haohmaru>
smells like nxp
slobodan_ has joined #openocd
loki_val has quit []
crabbedhaloablut has joined #openocd
slobodan_ has quit [Read error: Connection reset by peer]
slobodan has joined #openocd
<Haohmaru>
btw, my daplink board went in the trash... i've been too sloppy and didn't check everything at the end, so two signals of two SPIs are swapped... found that out as i was starting to write the code..
<PaulFertser>
Haohmaru: why reworking by cutting and adding jumpers wasn't an option?
<Haohmaru>
1) i don't like that sort of stuff and 2) my eyeball quality has gone down
<Haohmaru>
and there were a few more flaws with the board anyway, plus a few simple improvements that i didn't think of initially
<PaulFertser>
Fair enough
<jn>
microscopes can do wonders. (but indeed, fair enough)
<Haohmaru>
the new version should have the flaws fixed, software-controlled "power target with 3.3V" and the power switch which does this has a FAULT output which i wire up to the MCU so i should be able to know if, like, the target shat the pants and switch the power to VTGT off
<Haohmaru>
jn, do they grow on trees? ;P~
<jn>
unfortunately no, i'm lucky enough that there's an old (but good) one in my local hackerspace
<Haohmaru>
the flawed board could still be useful to do the actual basic experiments with the USB, if i get the USB working i could use it as a USB-to-UART
<Haohmaru>
also, this shall be a lesson to never trust myself, for once i didn't check my sh*t at the end and i had a big flaw like this on the most important thing
<Haohmaru>
i've been looking at some of those "USB microscopes" for soldering, but in any case, cutting tracks is not my thing.. i've done it at $job, but i highly dislike it
<PaulFertser>
jn: here there's old cameraless "Mantis" and it seems to be cool but I didn't have a need for that yet.
<karlp>
I've heard that many of the usb ones have too much latency for soldering under, fwiw. no personal experience with cheap ones.
<Haohmaru>
karlp, at $job we had a very cheap/silly one with a resolution of 640x480, there was several seconds latency, before i found the program "guvcview", with this one it's close to realtime
<Haohmaru>
i don't remember what i used first to view it, maybe something like mplayer/mpv
<PaulFertser>
:D
<Haohmaru>
it's not even bad, except for the focusing distance... in order to focus you have to have the thing very close to the board, which leaves very little space for the iron
<PaulFertser>
The man page says: mpv av://v4l2:/dev/video0 --profile=low-latency --untimed This plays video from the first v4l input with nearly the lowest latency possible.
<Haohmaru>
that probably not what i've tried, it was years ago and i don't think i had any fancy options
<Haohmaru>
but guvcview is available in debian and "it just works"
<PaulFertser>
Right, and you have all the v4l controls to adjust right there.
<Haohmaru>
now they bought a newer "microscope" at $job, it has a higher resolution, but it doesn't have neither USB nor HDMI nor nothing, an on-board LCD display
<Haohmaru>
it can focus from a longer distance (good), but the viewing angle on the LCD is poor, it's one of those crap LCDs with severe color-shift
<jn>
we have an old (but post-soviet) russian microscope at the space, no idea how it ended up here (in westernmost germany)
<Haohmaru>
oh wait, it *does* have USB, but is it merely for power input
<Haohmaru>
actually, it does work over USB.. huh
<Haohmaru>
and with the above mpv command it works in realtime
<Haohmaru>
the auto-exposure always sux, why don't they give a f*cking manual exposure adjustment >:/
<PaulFertser>
Don't they?
<Haohmaru>
well, if they do, where is it
<PaulFertser>
You can run v4l2-ctl in another terminal.
<PaulFertser>
Or use guvcview like you did before and it should have control there.
<Haohmaru>
i ran guvcview already
<Haohmaru>
neither on the cheaper one nor on this one did i find a way to control the exposure
<PaulFertser>
Doesn't exposure setting in guvcview affect anything?
<Haohmaru>
surely i'm unfamiliar with "USB cameras" but i do have a real photocamera that also shoots video, so i sorta know how things look like
<Haohmaru>
well, guvcview only has stuff like brightness, contrast, saturation
<Haohmaru>
those are post-effects
<PaulFertser>
Hm, any USB camera should have more
<PaulFertser>
What does v4l2-ctl --list-ctrls say?
<PaulFertser>
If it's there then should be available in guvcview too.
<Haohmaru>
i don't have that program
<Haohmaru>
okay, that prints a pile of things
<PaulFertser>
Is exposure setting in there?
<PaulFertser>
Yes. So must be available in guvcview too somewhere in that GUI.
<Haohmaru>
guvcview does show sliders and stuff for these things, but none of them appear to do anything, not even the basic brightness/contrast
<Haohmaru>
those sliders do work on the cheaper 640x480 camera i mentioned
<Haohmaru>
yeah the cheap one had only like 3-4 sliders, this one has much more, including gamma, white balance, what not.. but none of them do anything
<Haohmaru>
the picture is overal dark, probably the shiny bits (like solder joints) over-expose too much and cause the stupid auto-exposure to turn things down too much
<PaulFertser>
Probably some auto thing needs to be first turned off.
<Haohmaru>
it begins to smell like whoever made this has cut some corners here and there and maybe sploshed a firmware for a fancier camera onto a dumber camera and just left those parameters as if they are real, but they ain't
<Haohmaru>
with the CLI i managed to change some of the parameters (like, gamma, etc) but there is zero effect in the actual picture
<Haohmaru>
it's like you're turning some values in RAM ;P~
<Haohmaru>
the auto_exposure in guvcview is shown as a drop-down box, and it's grayed-out
<Haohmaru>
hm, i think the device lists these parameters incorrectly, "menu" probably means it should give N options with "names" but i guess it doesn't, so guvcview just shows an empty (grayed-out) drop-down box
<PaulFertser>
Shitty devices are shitty...
<Haohmaru>
yes, this is some no-brand camera too, even if it's not as cheap and looks fancier
<Haohmaru>
i tried uvcdynctrl, it prints a pile of "libwebcam: Unknown blahblah, Invalid blohbloh"
<Haohmaru>
and for the auto_exposure it says type=choice, values = { }, default=0
<Haohmaru>
enough fiddling with this junk-o-scope
<PaulFertser>
Sometimes only certain exposure values do anything at all.
<Haohmaru>
clearly the software on that camera is lousy and someone glued some codez together and "it compiled" ;P~
<Haohmaru>
then they shipped it
slobodan has quit [Ping timeout: 268 seconds]
MGF_Fabio has quit [Ping timeout: 252 seconds]
Haohmaru has quit [Quit: saionara]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #openocd
nerozero has quit [Ping timeout: 268 seconds]
Hawk777 has joined #openocd
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]