cyrozap_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
crabbedhaloablut has joined #openocd
tsal has quit [Ping timeout: 255 seconds]
tsal_ has joined #openocd
tlwoerner_ has joined #openocd
tlwoerner has quit [Ping timeout: 245 seconds]
Hawk777 has joined #openocd
nerozero has joined #openocd
nerozero has quit [Read error: Connection reset by peer]
Hawk777 has quit [Quit: Leaving.]
nerozero has joined #openocd
Quello has joined #openocd
<Quello>
How the OpenOCD to create a SWD communication?
<PaulFertser>
Quello: please rephrase, the question is unclear.
Haohmaru has joined #openocd
<Quello>
Background: The team has developed a ZynQ-based SWD FPGA IP, which has a corresponding device under Linux /dev. Now I am required to modify the OpenOCD communication source code to achieve burning or debugging of our target chip by running OpenOCD on ZYNQ.
<Quello>
Hardware connection: The SWD communication cable of the target chip is connected to the corresponding SWD cable assigned by ZYNQ
<Quello>
Software implementation: ZYNQ uses AXI4 communication
<Quello>
Question: Does anyone know what the process is for me to achieve this goal? OpenOCD source code I should how to change? Where is the change of location? Thank you!
<PaulFertser>
Quello: SWD is a debug connection for ARM cores. Do you mean you have an ARM _softcore_ in an FPGA?
nerozero has quit [Ping timeout: 264 seconds]
<Quello>
There are now two boards, ZYNQ and PSOC4, which are connected via SWD. There is a Linux system on ZYNQ, and it implements the FPGA of SWD communication, and the FPGA can access the DAP of PSOC4 through the IP of SWD, now I want to port an OpenOCD on ZNYQ, and achieve access to PSOC4 through OpenOCD.
<PaulFertser>
Quello: do you expect Zynq to just bitbang SWD or what?
<PaulFertser>
Or what kind of FPGA support for the SWD _host_ was implemented?
nerozero has joined #openocd
<Quello>
No, I just want to make the communication between OpenOCD and PSOC4 via the SWD IP of FPGA
<PaulFertser>
What's "SWD IP of FPGA"?
<Quello>
There is a PL source in ZYNQ, so we can realize the SWD communication by FPGA, and we can find our FPGA device in /dev of Linux, we can operate the device to access the DAP of PSOC4
<PaulFertser>
What kind of API does your "FPGA device in /dev" provides?
Quello has quit [Quit: Client closed]
Quello has joined #openocd
<Quello>
FPGA has provide some registers, we can access those REG by AXI communication.
<PaulFertser>
Quello: can you get more technical please? You said you have some device node in /dev , ok, so what kind of operations are supported on it? Some IOCTLs? Which one?
<Quello>
Yes it supportes IOCTLs, I want to known where the OpenOCD does this
<PaulFertser>
Quello: what IOCTLs
<PaulFertser>
Quello: look buddy I'm a volunteer here and somehow the way you interact isn't encouraging.
<Haohmaru>
PaulFertser, "you're hired!"
wingsorc has quit [Remote host closed the connection]
wingsorc has joined #openocd
Quello has quit [Quit: Client closed]
nerozero has quit [Ping timeout: 258 seconds]
nerozero has joined #openocd
Quello has joined #openocd
Quello has quit [Client Quit]
<PaulFertser>
What a weird fellow...
<karlp>
corpo life...
<Haohmaru>
"all i know is my deadline is friday"
<Haohmaru>
PaulFertser, did he bother you on privmsg? ;P~
<PaulFertser>
No :)
<Haohmaru>
huh, i'm surprised
<Haohmaru>
btw, actually, i may end up using the stlink v3 at $home
<Haohmaru>
i'll have to find it somewhere under 256 layers of dust
<Haohmaru>
i wonder if it'll be faster than the kamami debugger
<Xogium>
at least it's not 1024 or worse, 2048
<Haohmaru>
another kilobyte's the dust
<Xogium>
hah hah
<Haohmaru>
sh*t, november is knocking on the door, i haven't really advanced with that board :/
<Xogium>
board for work heh ?
<Haohmaru>
hell no
<Haohmaru>
my 2nd attempt at "cortex-M with audio"
<Xogium>
oooh
<Xogium>
that sounds cool
<Haohmaru>
this one should be fast enough on paper, and the audio should work in both directions this time
<Haohmaru>
if you see PCM3060 - think twice
<Haohmaru>
huh, and i forgot i also have an atmel-ice, dayum, i have 3 debuggers o_O
<Haohmaru>
one might think i'm wealthy
<Haohmaru>
i should probably sell that one, it's the most expensive one
<Xogium>
Haohmaru: what are you intending to make with this ?
<Haohmaru>
the audio board?
<Xogium>
curiosity on my part because I also wish to make something that will require audio one of those days ;)
<Haohmaru>
for attempt2 i decided to keep the board small and unspecific to the actual final thing, so that it could be usable for other kinds of things with "MCU with audio"
<Haohmaru>
and also since it's 4 layer board
<Xogium>
ah, I see
<Xogium>
I wish to make an hardware text to speech instead of a software one, using a mcu that would run espeak ;) will require a high-end mcu, probably f7 from st
<Haohmaru>
my attempt2 is with H723
<Haohmaru>
altho i was also eyeballing a few other cortex-M7Fs from other vendors
<Xogium>
yeah but thing is imho st has very good doc ;) I don't know how the mcu world is, but for the sbc world I'd say st blows everyone out of the water with how much doc they've got
<Haohmaru>
SBC?
<Xogium>
behind no NDA you have to sign, and all of that
wingsorc has quit [Ping timeout: 240 seconds]
<Xogium>
single board computers
<Haohmaru>
these MCUs are not really meant for SBC-grade usage
<Haohmaru>
cortex-M
<Xogium>
no I mean st makes mpus
<Xogium>
with escellent doc
<Xogium>
*excellent
<Haohmaru>
sure, no clue about those
<Haohmaru>
i was looking for MCUs, i can't really take advantage of multiple slow cores
<Haohmaru>
i need one very very fast core
<Xogium>
they go as far as explaining how to boot rom actually works and the pins
<Xogium>
*how the
<Haohmaru>
extra cores just add weight... might be nice to have one but..
<Xogium>
so I was saying, I have no idea how the mcu world is when it comes to doc, do other manufacturers bother to document as well as st does or not
<Haohmaru>
if i need one 400MHz core then i can't do my thing with 4 100MHz cores
<Xogium>
right
<Haohmaru>
from all documents i've read so far, i like the Atmel xmega ones the best
<Xogium>
oh, why's that ? Versatility ?
<Haohmaru>
because you have 1 big document explaining all peripherals on the whole series, this document is all you need to know how sh*t works and to write a peripheral library for example
<Haohmaru>
and then you have small datasheets for the chips which tell you what pins you have and how many of each peripheral and blahblah
<Xogium>
oh, that's neat
<Haohmaru>
outside of that there's all the additional appnotes about particular things, of course, but the main thing is 2 documents
<Xogium>
aye
<Xogium>
very well organized
<Haohmaru>
and then microsh*t took over and made it look like sh*t
<Xogium>
:/
<Haohmaru>
now you have individual single datasheet for each chip, like the rest of their crap
<Haohmaru>
that may be good in the eyes of some, but it's not great when they don't literally tell you "look now, aaaaall of these chips basically have identical peripherals"
<Haohmaru>
if you don't know, you have to compare datasheets for the details
<Haohmaru>
that sux
<Haohmaru>
the worst so far from what i've seen is NXP
<Haohmaru>
they require you make an account to get full datasheets
<Haohmaru>
and then they leak out their database and tell you "oops, btw change your password"
<Haohmaru>
i shortly looked at gd32h7xx datasheets, i liked how they just show you a schematic of the chip with all those boring minimum required things wired up
<Haohmaru>
all the capacitors and crap, crystals, etc..
<Xogium>
nxp never inspired me tbh
<Haohmaru>
i looked at them because a bunch of months earlier, they had the fastest cortex-M7F (by MHz at least)
<Haohmaru>
now gd32H7xx should come soon i think and they claim 600MHz too
<Haohmaru>
and they don't require you make silly accounts
<Xogium>
heh
<Haohmaru>
but i think they won't have fancy chip-configurator-grade tools like most other vendors, so there's that too
<Haohmaru>
but if the datasheets are written in a noob-friendly language - that may not be a problem
<Haohmaru>
the NXP datasheet i looked at was quite cold, you better not be a noob
<Haohmaru>
it'd be cool if there's more M7F options, faster ones, i actually don't care if it's ARM or risc-v or what, as long as there's one uber fast core, FPU, and gcc support
<Haohmaru>
but because i wanna hurry up, i can't wait for gd32h7xx, so went for stm32h723 which is in stock now, 550MHz, i made some guesstimation mathz and it should be fast enough, i hope so
<Haohmaru>
wish me luck with that x_x
<Haohmaru>
some folks gave me advice to look for an stm32h7xx with built-in flash, because some with external flash might actually execute the code slower, even tho the MHz specs are the same
<Xogium>
haha yes
<Haohmaru>
i hope i made the right choice
<Xogium>
I hope so too !
<Haohmaru>
can't someone make a 10GHz core chip? ;P~
<Haohmaru>
that should work for a ton of interesting audio things
<Haohmaru>
and an FPU that divides in 1 clock time ;P~