<Haohmaru>
that pic isn't listed as supported there
<PaulFertser>
Java h0rr0r it is for you then, what can I say...
<Haohmaru>
yes, just stay a long distance away from these chips
<Haohmaru>
don't even look at them
<PaulFertser>
I think I recently found a broken water cooler walking outside. Looked at the board and IIRC it was some PIC inside, and yes, I threw back to trash right away.
<Haohmaru>
when you wait for several minutes to flash a stupid pic with 2KB flash... you literally feel your beard growing
<Hammdist>
I was really happy when I found out one can compile for PIC with stock gcc and use -Os without a special license
<Hammdist>
anyways .. reason I am here .. I am trying to script an openocd session using telnet. problem is if I pipe data into telnet cli, it does not wait for responses, it seems to just quit when the input has been fully transmitted. anyone here knows a fix for this?
<Haohmaru>
Hammdist, eh, no, unless you mean the "MIPS" pics, but those are MIPS
<Haohmaru>
nope
<Haohmaru>
haven't used telnet
<Hammdist>
yea pic32 are/(were?) mips iirc
<PaulFertser>
Hammdist: telnet is suboptimal for the purpose, if you really need remote control then use the RPC socket probably?
<PaulFertser>
Or probably just do everything you need in Tcl directly.
<PaulFertser>
Or you can go weird way scripting GDB to send "monitor" commands.
Guest80 has joined #openocd
<Guest80>
Hi all. newb to OpenOCD here. I would like to flash armv8r target from my raspberry pi, but the openocd version I got from apt does not support that target. Do I need to compile my own OpenOCD somehow to enable the support for this target?
<PaulFertser>
Hi Guest80
<PaulFertser>
Guest80: yes but that should be really straightforward. Also, hm, flash, is there a flash driver for your target available?
<Guest80>
I am not sure, where to look? I have the board, target and cpu scripts for that.
<Guest80>
Thanks for quick respone PaulFertser
<PaulFertser>
Guest80: are those scripts upstream? Please use some pastebin to show.
<Guest80>
I think I cannot share them unfortunatelly, they were distributed by the supplier. Maybe I can try compiling the openocd first with the support? Could you please guide me how to do that?
<Guest80>
I searched around and they should be part of the aarch64 "family"
<Guest80>
by the way I will be using FTDI mini module to flash via JTAG, which is supported by OpenOCD
<PaulFertser>
Guest80: why should I bother if you are not sharing text configs even, wtf?
Guest80 has quit [Quit: Client closed]
<PaulFertser>
Am I not fair here?
<karlp>
no, they should obviously speak to their supplier for help.
<Haohmaru>
what's this?
<Haohmaru>
some vendor-modified openocd?
Hawk777 has joined #openocd
<Hammdist>
it's working .. it's working .. I get coherent 32-bit values out of the JTAGG interface from an ecp5 using only 66 lines of verilog
<Haohmaru>
are you blinking a LED with that FPGA thing? ;P~
<Hammdist>
actually the goal is to replace blinking LEDs as I have only remote access to a Pi connected to the FPGA. so I want to get debug information out without having to look at the board ...
<Haohmaru>
change the LEDs to a buzzer
<Haohmaru>
>:)
Haohmaru has quit [Quit: saionara]
<Hammdist>
if I send "a ; b ; c" to the rpc port I get only the output for `c`. is this intended? is there any fix for it?
<Hawk777>
Not sure if it’s intended, but you could just send the three commands separately, each with the EOF marker after it?
<Hammdist>
meh, with that approach one can get lock-ups if there are too many queued commands and one doesn't read until all the commands are written. so one needs kind of a multithreaded or select-driven program
<Hawk777>
Ah, yes, I was assuming you could send one command, read its reply, and then send the next.
<Hawk777>
Even if you don’t actually do anything with the replies until you’ve collected all three.
<Hammdist>
nah feeding them one at a time would be badder for latency
<Hawk777>
Though if you know the commands are short and there aren’t very many of them, you might be able to just assume they’ll fit in the kernel pipe buffer.
<Hawk777>
E.g. on Linux I don’t think a pipe buffer can ever be <4k, so if your three commands fit in that space, score.
<Hawk777>
If you have a longer stream or anything is user-provided, obviously not helpful.
<Hammdist>
it looks like my commands will just barely fit in 4k though. something else must be wrong with my program then
<Hawk777>
It’s hanging in write()?
<Hammdist>
no, in read actually now that I checked. it's due to unexpectedly strange behavior of Ruby's String.split method
<Hammdist>
ah it's working now. RPCs from Ruby. result: [0.025915064, 2569567] left value is time taken to take 1 sample of the FPGA clock, right value is number of FPGA clock ticks at 100mhz that elapse during this time (2 samples were taken back to back to obtain these values)
<Hawk777>
Great!
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #openocd
diddly_ is now known as diddly
<gamiee>
hi everyone, I just would like to ask if it is possible for anyone from maintainers to checkout my TCL patch please? https://review.openocd.org/c/openocd/+/8593 From my side, it works pretty well, so I would love to see it upstream. Thanks
<zapb__>
gamiee, I pushed Antonio and Tomas
nerozero has quit [Ping timeout: 252 seconds]
<borneoa___>
gamiee: hi Marek, sorry but I'm overloaded with too much stuff. I don't expect to check it within this week and then next week I should be completely off-line. Please ping me again if I don't return to the review in 2 weeks
<gamiee>
Hi borneoa___ , no worries, I totally feel that. I just wanted to remind myself. And I will do so. Thank you for fast answer and your time, I appreciate it a lot.
<gamiee>
zapb_ : thanks!
noarb- has joined #openocd
stefanct__ has joined #openocd
juri__ has joined #openocd
juri_ has quit [Ping timeout: 252 seconds]
cambrian_invader has quit [Ping timeout: 252 seconds]