aquijoule_ has quit [Read error: Connection reset by peer]
jybz has joined #openocd
thinkfat has joined #openocd
thinkfat_ has quit [Ping timeout: 256 seconds]
boru` has joined #openocd
boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
ildar[m] has quit [Read error: Connection reset by peer]
Jybz[m] has quit [Read error: Connection reset by peer]
lh has quit [Write error: Connection reset by peer]
Jybz[m] has joined #openocd
lh has joined #openocd
ildar[m] has joined #openocd
Jybz[m] has quit [Quit: node-irc says goodbye]
lh has quit [Quit: node-irc says goodbye]
ildar[m] has quit [Quit: node-irc says goodbye]
nerozero has joined #openocd
Guest51 has quit [Read error: Connection reset by peer]
klysm has quit [Quit: Lost terminal]
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
klysm has joined #openocd
Jybz[m] has joined #openocd
lh has joined #openocd
ildar[m] has joined #openocd
Steffanx has joined #openocd
lh has quit [Quit: Client limit exceeded: 20000]
ildar[m] has quit [Quit: Client limit exceeded: 20000]
Jybz[m] has quit [Read error: Connection reset by peer]
Jybz[m] has joined #openocd
lh has joined #openocd
ildar[m] has joined #openocd
lh has quit [Quit: Client limit exceeded: 20000]
ildar[m] has quit [Quit: Client limit exceeded: 20000]
Jybz[m] has quit [Quit: Client limit exceeded: 20000]
Jybz[m] has joined #openocd
Jybz[m] has quit [Remote host closed the connection]
Jybz[m] has joined #openocd
lh has joined #openocd
ildar[m] has joined #openocd
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #openocd
akaWolf has quit [Ping timeout: 258 seconds]
akaWolf has joined #openocd
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #openocd
Guest51 has joined #openocd
<Guest51>
cyrozap PaulFertser Sorry for my delay in responses -- regarding the conversation earlier on in the week: The Sharc isnt of too much interest for me (i'm more interested in the Altera). The Altera chip is the one which has the Serial line wired to it
<Guest51>
oh my name changed back...
<PaulFertser>
Guest51: Altera handling some serial communication to receive external commands?
<PaulFertser>
Guest51: are you sure?
<Guest51>
yeah i used a multimeter to track from the external plug, to a MAX3490 => Altera
Guest51 is now known as Matt144
<PaulFertser>
Matt144: I'm afraid then you're SOL man
<PaulFertser>
Matt144: gotta find someone who'd dump serial communication for you.
<PaulFertser>
You can of course try to brute-force it... Chances are commands are few bytes.
<Matt144>
yeah i made a small program to do that
<Matt144>
i dont think im going to get the serial communications dumped
<PaulFertser>
Matt144: but what if you prepare a ready-made board with connectors so that it would be trivial to capture traffic for someone who's servicing one of those?
<PaulFertser>
Probably board with connectors, PHY and raspberrypi, so it would not require any skills.
<PaulFertser>
Or even do a field trip yourself.
<Matt144>
rock up to the local army base and ask to borrow a tank for a day
<Matt144>
cheers boys
<PaulFertser>
Matt144: I do not see how it can be possible to deduce protocol from an FPGA bitstream unless the bitstream was already RE like they do in project IceStorm etc.
<Matt144>
:)
<PaulFertser>
They probably have civilian techs.
<Matt144>
sorry -- whats an RE?
<PaulFertser>
reverse engineering
<Matt144>
ah yep
<Matt144>
uhh one sec let me fetch something
<Matt144>
this is the company that made the camera -- as well as the newer models:
<karlp>
or sorry, between the alterra and the camera.
<karlp>
you found the link between the camera and the fpga right?
<Matt144>
when you say camera do you mean sensor?
<Matt144>
the FPGA is in the camera
<karlp>
yes.
<Matt144>
yeah the sensor is connected to the SHARC
<Matt144>
and the serial lines are connected to the Altera
<karlp>
The Altera chip is the one which has
<karlp>
| the Serial line wired to it
<karlp>
so what's that meant to mean?
<karlp>
either way, you believe there's a serial line that has commands you're trying to find out,
<karlp>
why aren't you sniffing them?
<karlp>
you're ~never going to figure it out by looking at an fpga bitstream, or at least, it's certainly much more straightforward to just listen to the serial stream.
<Matt144>
the camera is a receiver of the serial commands
<karlp>
yes....
<Matt144>
i only have the receiving end
<Matt144>
how can i sniff if i only have a receiver
<karlp>
with a logic analyser?
<karlp>
sorry, that was self evident to me, but perhaps not to you :)
<karlp>
hang on, you're back to the serial link goes out of the "camera unit" again now aren't you?
<karlp>
are you trying to decode serial interface to external, or inner interface between sharc/fpga and sensor?
<Matt144>
ok so -- This camera has a RS485/422 pins on it. Commands must be sent over that in order to control the camera (zoom, (auto?)focus, WHOT/BHOT, etc)
<Matt144>
The reason i was looking at the FPGAs is because i was under the impression that i could pull the contents of the flash through the FPGA(s) via jtag
<karlp>
and youv'e worked out some of the commands already right?
<Matt144>
no -- i've not started running the brute force script as of yet
<karlp>
you can probably pull out the contents of the flash easier by talking to the flash itself, but sure, that's just a method.
<Matt144>
yeah im waiting on a small breakout board before desoldering the flash
<karlp>
does the serial link go to the sharc or the fpga?
<Matt144>
its too small to attach pins or anything to
<Matt144>
the serial link goes to the Altera
<karlp>
(get a better clamp ;) it's the TE28F right? U32?
<Matt144>
yeah the clamps i found were like 200+ usd
<karlp>
well, yeah, but desoldering can be problemenatic depending on how many test boards you have :)
<karlp>
honestly, I'm surprised it goes to the alterra, but ok :)
<karlp>
do you have any "standard" software that plugs into the serial link?
<karlp>
dumping the bitstream for the fpga will be (IMO) not an easy method of figuring out the serial commands....
<karlp>
it actually soudns insanely complicated.
<Matt144>
why are you more suprised about it going to the Altera rather than the SHARC?
<Matt144>
(noob question...?)
<Matt144>
why does it make more sense for it to be on the SHARC
<karlp>
the sharc is a dsp, sure, but it's still a cpu as well, so handling serial commands felt like amore natural fit there.
<karlp>
doesn't really matter.
<karlp>
fpga might be running nios or similar anyway :)
<Matt144>
if it was would that make it "easier"?
<karlp>
maybe, you'd be dealing with a known instruction set for decodeing the flash dump
<karlp>
your fpga bitstream is "magic alterra bits"
<karlp>
does it describe a wire? does it describe a serial byte? who knows!
<jybz>
worst, it describe logic electronics, gates, ... Milions of them. How, and where, to find the packet of gates that are for one command ?
<Matt144>
no idea
<karlp>
^^
<Matt144>
i figured i'd cross that bridge when i came to it tbh
<karlp>
well, you're at that bridge :)
<Matt144>
i figured i'd get the flash dump and run strings and binwalk and hope for the best
<karlp>
I mena, the _easist_ way would be finding something that can natively talk to the camera....
<karlp>
sure, maybe you'll get luucky :)
<karlp>
so where are you stuck now?
<Matt144>
well -- i've been doing a bit of reading on flash
<karlp>
you found jtag for the fpga, and are stuck trying to read out flash?
<Matt144>
yeah
<Matt144>
i was hoping i could read the flash from the FPGA via JTAG
<karlp>
do you see both the sharc adn the fpga on the jtag chain?
<Matt144>
yeah
<karlp>
it's _probably_ possible, but not my field, reading off the flash directly is certainly easier
<karlp>
is the flash only connected to the sharc?
<karlp>
or is it a flash fpga part with onboard flash?
<karlp>
ie, does the sharc load the bitstream onto the fpga?
<Matt144>
both the sharc and the altera are connected to the flash (im surprised too) if you look at the image you'll see 5 lines leading directly to the SHARC, the other lines going into vias lead to the altera
<jybz>
how many flash there are ?
<Matt144>
1
<Matt144>
the sharc does have onboard flash if i remember correctly too
<Matt144>
anyways i was told that i wasnt able to fetch the flash from the FPGA via J-tag so i gave up on that
<Matt144>
so i've just been kinda waiting / trying random stuff until the breakout board comes
<karlp>
the pinout suggests they're using different addresses.
<karlp>
cute.
<Matt144>
yeah thats what i figured
<Matt144>
so, theres something called CFI... this isnt that -- correct?
<karlp>
looks likie it predates it. flash is from 98.
<karlp>
you probably still can, but you're doing it via bitbanging boundary scan or similar.
<Matt144>
Paul mentioned "memory-mapped parallel flash"
<karlp>
yeah, that's if you run something on the "host" cpu and access it from there
<karlp>
but as you can see, even the sharc host can only see part of the address rnage :)
<Matt144>
so what is the "interface" this flash uses? if that question makes sense? (tried googling / researching but if the answer didnt slap me in the face i wouldn't see it)
<Matt144>
is it some old forgotten thing? does it have a name?
<Matt144>
btw i really appreciate the help / ideas you guys have given me, im pretty in over my head with this :)
<karlp>
datasheet calls it "CUI" but it's just "follow the intel datasheet for everything"
<karlp>
it's kinda ~raw parallel flash
<karlp>
what's the end goal? do you have a few thousand of these you got off the back of a trucka nd you want to repurpose or what?
<Matt144>
nah i've thought thermal cameras were cool for years and now i finally have one
<Matt144>
got them from an ex military auction
<Matt144>
we paid 90 bucks for all 11 of them
<Matt144>
originally costing the tax payer 65k ish USD each
<Matt144>
bargin
<Matt144>
gonna send one to my mate for his farm, keep one at home for myself, one up in the country.... idk what to do with the rest
<Matt144>
make a little gimble for it... use it for spot lighting... idk
<Matt144>
its just cool
<Matt144>
oh and look for koalas
Matt144 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest51_ has joined #openocd
Guest51_ is now known as Matt144
<PaulFertser>
Matt144: probably set up an automated jig that would be recording sound in sync with serial protocol brute-forcing so that when/if you spot a command that alters the focus the mic would pick it up?
<PaulFertser>
Matt144: I mean so that you would be able to leave it running for weeks
<karlp>
do you even know which pins are serial on the screw connector?
<PaulFertser>
That's easy to trace to the serial PHY so I assume yes.
<karlp>
even if you know it's rs422/485, bruteforcing an unknown protocol sounds insanely tedious.
<karlp>
even just modbus has 16bit address space, + 8 bit function space, plus arbitrary lengths on data....
<karlp>
plus potential encryption
<PaulFertser>
Chances are it has some simple protocol if old FPGA handles it.
<PaulFertser>
But also unknown baud rate and parity...
<karlp>
sure, modbus is simple, but it's still got a _lot_ of room for explosions
<PaulFertser>
Probably those were also used on some other equipment, not only tanks?
<karlp>
yeah, I'd be spending my time finding some other head end equipment ...
<karlp>
there's a chance you can find nios2 object code in the flash, that might be feasible to dissassemble.
<Matt144>
its a mystery what the middle 3 pins are -- i dont think they are connected
<Matt144>
its a 10 layer PCB and xray wont get through the ground plane
<Matt144>
havnt been able to beep them out anywhere on the PCB with the multimeter either
<PaulFertser>
Matt144: the idea to desolder the flash and read it out and then trying to find some softcore cpu firmware inside is so far looking most realistic.
<Matt144>
yeah thats what i was thinking
<Matt144>
we've got 2 of the cameras cracked open -- i'll brute force on one and then do that to the other
<PaulFertser>
Matt144: there's another way if you can get FPGA pro help: for this specific part prepare configuration that would be dumping flash contents to serial, and upload it via JTAG temporarily
<Matt144>
sorry -- page 15
<PaulFertser>
Why did you open the second?
<Matt144>
the other one is open at my friends house so he can experiment and try to figure it out too
<Matt144>
"FPGA pro help" do you mean fpga professional help?
<Matt144>
thats actually not a bad idea
<PaulFertser>
Matt144: yes, pro as in someone who has enough experience with development for FPGA
<Matt144>
i know someone who does
<Matt144>
ill speak to him over the weekend
<PaulFertser>
It would require vendor tools of course
<Matt144>
yeah hes actually someone who i've bounced ideas off -- surprised we didnt think of that already :)
<PaulFertser>
And probably some jtag adapter that's compatible. Or the way to make vendor tools output an SVF file that would do this temporary configuration via JTAG.
<PaulFertser>
Matt144: you should also ask him if he thinks it's possible this thing might be using nios2 or or some other softcore.
<Matt144>
he said it might be possible they've "emulated a CPU on the FPGA bit that would be strange -- but not impossible"
<Matt144>
ill ask him those speciffic questions when i get a chance
<PaulFertser>
Why would it be strange though?
<PaulFertser>
Isn't it quite common?
<Matt144>
i dunno -- just what he said ahah
<jybz>
ok so this MAX pin[5-8] are the RS422 connections ?
<Matt144>
yep
<Matt144>
i didnt label exactly which ones they are at the time because i didnt properly understand it
<Matt144>
but now i do -- so i will soon
<jybz>
ok, maybe at boot, it would send few char, to you can probably find TX pairs, and find the baud rate.
<jybz>
s/to/so
<Matt144>
i've traced out the TX/RX pairs before
<Matt144>
just forgot to label them
<jybz>
ok ok
<Matt144>
it doesnt spit anything out on boot either which is unfortunate
<PaulFertser>
Nios for Altera and MicroBlaze for Xilinx should be pretty popular.
<Matt144>
thats sick
tarekb has joined #openocd
<Matt144>
thats super cool
<PaulFertser>
With integration into their vendor tools etc.
Haohmaru has quit []
<PaulFertser>
So dumping the flash and trying to find nios code there is worth it.
<jybz>
but, can you find the closed source nios code ?
tarekb has quit [Read error: Connection reset by peer]
<jybz>
closed source nios synthetized code *
<PaulFertser>
jybz: wouldn't it be stored in flash as a plain binary?
<jybz>
yes, but I'm not sure if the softcore is placed in a specific part of the FPGA, if it is fexible, it can be "everywhere", and the gates behind would change. But I've no idea, I'm probably wrong.
<Matt144>
i gotta head to bed, gotta get up early to install some cameras at a mates place in the morning! Thanks so much for the help, discussion and ideas
<PaulFertser>
The softcore might be anywhere, but firmware for it I'd expect to be stored as is somewhere.
<jybz>
I imagine the FPGA as a breadboard, and you can place things in different places, depending on your needs, your installation.
<jybz>
and the flash is probably just an image of this breadboard, and the softcore can be split with another function inbetween.
<PaulFertser>
jybz: right, but where would the softcore get its firmware from for execution?
<PaulFertser>
It's not like you're likely to emulate ROM there if you have real ROM attached.
<jybz>
hum yes, you mark a point, somewhere, there is probably a ROM inside with instruction set
<urja>
the softcore firmware could be in preloaded contents for the FPGA RAM blocks that are being used as ROM ... that might end up in chunks but still recognizable... or it loads it runtime from an address past the FPGA bitstream and it's neatly all there
<urja>
well... runtime as in after bitstream loading
<jybz>
and what will be the commands ? 0x0022
<jybz>
They won't be named
<PaulFertser>
You disassemble everything as nios II and try to spot some sensible portions.
<jybz>
Or maybe, if the RS422 is directly linked to the FPGA, the ASCII commands should be readable.
<PaulFertser>
hm, if it's really running nios it's likely to be somehow accessible runtime over JTAG
<PaulFertser>
Matt144: you should probably try to investigate how altera tools connect to nios core via jtag. Might be possible with OpenOCD if that's documented enough.
<PaulFertser>
I'd try vendor tools though
emeb has joined #openocd
<c4017w>
Anyone have a config file for Renesas RA2 series?
<c4017w>
oof, looks like I'll need to create a flash driver for it as well
<karlp>
marex has done a bunch of other renesas stuff, you might try poking them.
<karlp>
you might also look at gerrit, there might still be outstanding renesas support patches?
<marex>
karlp: not the micros (ra2 is I think a micro)
<marex>
rcar/rza/rzg are different divisions
nerozero has quit [Ping timeout: 265 seconds]
<c4017w>
karlp, can you link the page showing outstanding patches?
<marex>
it should be rather standard cortex-m config file
<marex>
does it have normal jtag interface or does it use the E2 emulator ?
<c4017w>
Thanks. marex it's SWD only, I was able to program it with a J-Link and J-Flash sogtware. Wouldn't I still need a flash driver in addition to the config file?
<PaulFertser>
c4017w: to write to an MCU flash you'd need to write a flash driver, yes. But you can debug without it.
<c4017w>
PaulFertser, thanks, as I thought. I do need programming capability, but I'll get the config file working first. Can't even get the thing to halt yet
<PaulFertser>
c4017w: what does it say?
<PaulFertser>
c4017w: does renesas provide enough docs for you to write a flash driver?
<c4017w>
'reset halt' returns TARGET: ra2a1.cpu - Not halted
<c4017w>
SWD DPIDR 0x5ba02477
<PaulFertser>
c4017w: but how about simply "halt"?
<c4017w>
PaulFertser, I really don't know what's involved with writing the driver yet. Will have to do some reseasrch first and look at existing drivers
<c4017w>
I've had mixed luck with just 'reset' and 'halt
<c4017w>
sometimes returns nothing, sometimes 'halt timed out, wake up GDB.', sometime works
<PaulFertser>
c4017w: basically, if you can overwrite flash with code running on the microcontroller, then you can write a flash driver.
<PaulFertser>
c4017w: nothing would mean it halted.
<c4017w>
Ok looks like that's working now? I was having another issue where the 'blank' return message wasn't being sent through the rpc channel, but cannot reproduce now
<c4017w>
PaulFertser, just wondering, why is it 'reset halt' for some, but only 'halt' for others? Is there something I can change to make 'reset halt' work as well?
<PaulFertser>
c4017w: reset halt might be tricky if the target has some ROM code running right after reset and hardware prevents you from accessing it.
<PaulFertser>
c4017w: basically what reset halt does is setting up a vector catch on reset exception and then resets the target by SRST if you enabled it or by SYSRESETREQ bit if it's supported.
<c4017w>
ah ok
<PaulFertser>
c4017w: so in certain cases getting meaningful results might be tricky, you can take a look at psoc*cfg if you want to see something horrible.
<PaulFertser>
c4017w: and plain "halt" just tries to halt, right now, without resetting anything.
<c4017w>
that does look horrible.. I'll rather just add a special case for this micro in my script
<c4017w>
As for flash programming, there is another option to just write to flash directly right? Without having to write the peice of code that runs in ram?
<PaulFertser>
c4017w: if the flash peripheral is controlled with memory-mapped registers, yes. But that's usually much slower.
<c4017w>
Ok, thanks for you guidance. Unfortunately, I have to get this done quickly, not neatly, and I suspect the memory mapped approach will be easier if it's supported by this chip.
<c4017w>
although first I will look if there's already an m23 flash driver existing
<PaulFertser>
c4017w: there's no such thing as m23 flash
<PaulFertser>
c4017w: each vendor has its own flash peripheral
<c4017w>
Right, I mean the assembly ram routine in m23 flavor, so I have a starting point. Or is the assembly flavor of m23 similar to m4? That's all I have experience with
<PaulFertser>
c4017w: some chips have ROM functions you're to call for flashing. Some vendors provide binary-only libraries you have to link with for flashing. You have to find out more about your particular target.
<PaulFertser>
c4017w: should be pretty similar of course, still Thumb2+ I guess. And you can do it in C too :)
<c4017w>
I have 32k of ram to work with, so yeah, I could probably just do it in C. But first lets see what I even have to do lol
<PaulFertser>
c4017w: I guess if you take Cortex-M0+ assembly code it'll run as is on Cortex-M23 too.
dreamcat4 has quit [Ping timeout: 250 seconds]
dreamcat4 has joined #openocd
<marex>
PaulFertser: they dont really talk about the flash much in the ra2 docs, hum
<c4017w>
seriously, they keep mentioning the flash control block, but there is no descriptions of it's registers...