boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
<jybz>
Hi PaulFertser, thank you. I manage to connect the flash with flashrom and the jlink, read/dump the flash. But I never was able to erase. Worst, somehow, the "Chip status register: Block Protect 4 (BP4)" wasn't set and sets it by itself. I don't find flashrom argument to controle the registers. Here where I am. Good night (what remains ^^)
<Matt144>
PaulFertser: When you say DSP are you referring to the SHARC to the ALTERA (or both?)
<Matt144>
or the*
nerozero has joined #openocd
akaWolf has quit [Ping timeout: 250 seconds]
akaWolf has joined #openocd
Hawk777 has quit [Quit: Leaving.]
thinkfat_ has quit [Quit: Konversation terminated!]
<PaulFertser>
jybz: probably you just need to change /WP pin state. How did you connect it?
<PaulFertser>
Matt144: to the SHARC. I think ALTERA is just an FPGA, it doesn't have a DSP hard or softcore does it?
<jybz>
I connected /WP to +vcc
<jybz>
PaulFertser: any idea how I can reset the PB4 bit ?
<jybz>
I didn't saw any options in flashrom for it (except refused patch in the mailing list if I'm correct)
<jybz>
I read the flash datasheet, and it seems only to be a software bit, not a fuse. The fuse are reset '0'.
<PaulFertser>
jybz: yes, +Vcc is appropriate. If you're able to fully read the flash it means you're pretty close to having it working. Have you tried -E option?
<jybz>
PaulFertser: no, I didn't. <icon> on #flashrom didn't recommand to do anything on the flash, he takes it with a lot of care
<PaulFertser>
jybz: I guess people there are more experienced than me in using flashrom. Make sure you have the whole dump first. You can inspect (and exctract it) with binwalk.
<PaulFertser>
jybz: because you would want to save individual calibration data for the device.
<jybz>
Chip status register: Block Protect 4 (BP4) is not set
<jybz>
it came back itself
<PaulFertser>
jybz: most likely the individual calibration data is intact, but you should check it with binwalk on your full flash dump.
<jybz>
Ok, I had a dump, i did it three times, compared with sha256sum, but I not sure if they are well.
Jybz[m] has joined #openocd
<jybz>
Ok, the dump after this tries to erase and to flash, has exactly the same sum
<jybz>
As the PB4 bit is reset, I continue this adventure in #flashroom.
<jybz>
Thank you PaulFertser, I will let know know ;)
<PaulFertser>
jybz: good luck!
zjason` is now known as zjason
renrelkha_ has joined #openocd
renrelkha_ is now known as renrelkha
renrelkha has quit [Read error: Connection reset by peer]
renrelkha has joined #openocd
renrelkha has quit [Changing host]
renrelkha has joined #openocd
Hawk777 has joined #openocd
nerozero has quit [Remote host closed the connection]
nerozero has joined #openocd
Hawk777 has quit [Ping timeout: 244 seconds]
Hawk777 has joined #openocd
nerozero has quit [Ping timeout: 272 seconds]
Hawk777 has quit [Quit: Leaving.]
Hawk777 has joined #openocd
<cyrozap>
Matt144: You can read/write the flash connected to some FPGAs from OpenOCD if the FPGA is supported by one of the "proxy" bitstreams. Unfortunately, that only works for Xilinx FPGAs right now, but the idea is to program the FPGA with a bitstream that enables reading/writing the flash through special JTAG instructions.
<cyrozap>
But I really don't think you need to go that far to control the focus motor. Assuming that the ADSP/SHARC is running everything, and that's the chip you're talking to via whatever external interface the camera has, you just need to determine the command you need to send to the ADSP that controls focusing. The easiest way to do that is to just sniff the communications when the camera is being controlled
<cyrozap>
by software/hardware that already knows how to do that, but if you don't have access to that, then the next best thing would be to dump and disassemble the firmware to find where commands are processed, then just try all the commands until you find the one that controls the focus.
<cyrozap>
The important thing is, don't reverse engineer anything you don't have to (unless you want to and you're having fun, of course).
<cyrozap>
But reverse engineering an FPGA bitstream is several orders of magnitude more difficult than disassembling and reverse engineering firmware, so if it were me, I'd start with the low-hanging fruit (the ADSP firmware) first, and just treat the FPGA like some black-box fixed-function hardware.
<PaulFertser>
cyrozap: the problem is that it's unclear how the ADSP firmware can be obtained.
<cyrozap>
(link/host boot) pins. 32-bit and 16-bit host processors can be used for booting. The processor also supports a no-boot mode in which instruction execution is sourced from the external memory."
<PaulFertser>
cyrozap: does it mean there's no internal program memory in this device?
<cyrozap>
This chip doesn't have any internal flash, so I think all Matt144 would need to do to dump the firmware is power up the camera, attach JTAG, then dump the internal SRAM and external memory.
<PaulFertser>
cyrozap: but is there any JTAG software that can handle that target?
<PaulFertser>
cyrozap: so probably this board has two flash chips: one for the FPGA and another for the ADSP?
rue_shop2 has quit [Ping timeout: 268 seconds]
<cyrozap>
No, my thinking is that first the FPGA loads its bistream from flash, then it either 1) loads the ADSP firmware from the same flash chip into the ADSP's SRAM, or 2) makes the firmware accessible to the ADSP over the ADSP's external memory interface.
rue_mohr has quit [Ping timeout: 250 seconds]
<cyrozap>
So the flash is shared between the FPGA and the ADSP, with the FPGA acting as the arbiter of that access. Or the FPGA doesn't grant direst access to the flash at all, and just loads the ADSP's SRAM with the firmware from flash one time at boot.
<cyrozap>
And if Matt144 isn't opposed to using Windows and ADI's proprietary VisualDSP++ software (and the corresponding dongle), they could probably use that to dump the memories. Otherwise, they could use OpenOCD's RPC interface to write their own code to interact with the JTAG hardware based on whatever specs ADI has released regarding that.
<cyrozap>
Or they could just desolder and dump the flash.
<cyrozap>
But then the problem becomes, how do you disassemble the code? It doesn't look like any of the popular interactive disassemblers support the SHARC ISA, so support would need to be added to one of them (Ghidra would probably be easiest, and it would enable decompilation for free).
Hawk777 has quit [Quit: Leaving.]
rue_shop2 has joined #openocd
rue_mohr has joined #openocd
vpelletier has joined #openocd
<vpelletier>
Hello. I am trying to debug a linux kernel issue on a riscv board (hifive-unmatched) and I suspect the addresses I am seeing are the virtual addresses, but used as physical addresses.
<vpelletier>
I am running openocd 0.11.0-rc2 as of debian sid
<vpelletier>
(package 0.11.0~rc2-1)
<vpelletier>
taking a glance at the source code (target/riscv/riscv.c) there seems to be mmu support, but being very new to openocd I may be doing something stupid, like not enabling some option
<vpelletier>
(...my gdb config is based on..., but the rest is path management and seem irrelevant to this issue)
<PaulFertser>
vpelletier: btw, not sure if it helps or confuses but riscv has an OpenOCD fork that's more advanced than the upstream.
<PaulFertser>
vpelletier: and you can use "mdw phys" instead of plain "mdw", that should tell the target code to bypass MMU.
<vpelletier>
I noticed that, and this is actually why I checked the source code for mmu support... could this support be better in their fork ?
<PaulFertser>
idk
<vpelletier>
mmh... what is mdw ?
<PaulFertser>
vpelletier: memory dump word OpenOCD command
<PaulFertser>
vpelletier: you can run OpenOCD commands via Telnet or with "mon mdw" from GDB.
<vpelletier>
mmh, both with and without phys give the same result... it looks like both are interpreted as physical
<vpelletier>
"(gdb) info reg" tells me "pc 0xffffffff80003da8 0xffffffff80003da8 <riscv_of_processor_hartid+144>", which looks like a virtual address to me
<PaulFertser>
vpelletier: if MMU is enabled info reg is supposed to be showing virtual addresses
<vpelletier>
so I would expect it to find "nothing" (zeroes ? some memory controller error due do unavailable address lines ?) if this interpreted as a physical address
<vpelletier>
ah, yes, this is my understanding: the cpu itself is using the virtual addresses
<vpelletier>
I mean, then gdb (or openocd) seem to be using this as a physical address
<vpelletier>
(gdb) thread apply all bt: https://hastebin.com/biqutokoga.txt the first core is not used by the kernel, so it is in what I undertsand as the machine-mode parking code loop, waiting for something to tell it to jump to some actual code, and it would have its mmu disabled (...and probably no caller)
Fleck has quit [Remote host closed the connection]
<vpelletier>
anyway, I'll build riscv's version to see if it changes anything
Fleck has joined #openocd
<vpelletier>
on a very tangential note, should "-rtos" be given when declaring each core, or just once as in the configuration file I use ?
<vpelletier>
...and it does !
<vpelletier>
building riscv's version lets me see stuff on virtual memory addresses
<vpelletier>
unfortunately lx-symbols is still not happy