crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #openocd
c4017 has quit [Ping timeout: 256 seconds]
Hawk777 has quit [Quit: Leaving.]
nerozero has joined #openocd
Steffanx- has quit [Ping timeout: 245 seconds]
Steffanx- has joined #openocd
Fist0urs has joined #openocd
Haohmaru has joined #openocd
michalkotyla has joined #openocd
Xogium has joined #openocd
<Xogium>
heya guys :) trying to flash external qspi flash on stm32f769i-disco with openocd and I noticed that for some reason, whatever I read back or write is always one byte misplaced
<Xogium>
for example there was this mbed example I tried which simply stored hello world directly in the flash. Reading back with openocd, it became, llo world
<PaulFertser>
Xogium: hey
<Xogium>
heya PaulFertser ! Long time no see
<PaulFertser>
Xogium: I think something like that was reported already. Not sure where, probably on the mailing list, I'll try to find.
<Haohmaru>
could it be address size in the command being off?
<Haohmaru>
like 24bit vs 32bit address
<Xogium>
maybe..? I'm all new to openocd let alone mcu
<Haohmaru>
no idea about qspi flash, but if it's similar to "normal" SPI eeproms, you have an spi command to read/write, where the command is usually the 1st byte, then the following byte(s) are for the address, and then any additional bytes are data
<Haohmaru>
this address chunk can be 8bit on the smallest ones, 16bit on the bigger ones, etc..
<Xogium>
hmm
<Xogium>
this is a 512 mbit qspi flash
<Xogium>
so 4-bytes addressing required
<Haohmaru>
how's the addressing done tho
<Xogium>
I'm not sure…
<Haohmaru>
like, there can be two eeproms of 1KB where one is 1024*8bits while the other can be 512*16bits
<PaulFertser>
Xogium: I suggest you stay on channel here, probably someone who works with f7 or h7 and QSPI remembers something.
<Haohmaru>
..could also be something completely different tho
<Xogium>
Haohmaru: do you mean block size/erase size and such ?
<Haohmaru>
no, not page size
<Haohmaru>
this is typically called "data organization"
<Haohmaru>
if the data organization is 512*16bit then you'd have 512 addresses, and there would be 16bit "words" at each address, and you wouldn't be able to read "byte by byte" like if it was 1024*8bit
<Haohmaru>
yet it's still 1KB worth of memory
<Haohmaru>
but that doesn't matter, i'd check how big the address is (in the SPI read/write commands) and how big the address is of whatever the code is that actually talks to that flash chip
<Haohmaru>
i mean, the address size as per the datasheet vs the actual address size being sent from the MCU that talks to it
<Haohmaru>
maybe it's 1byte off
<Xogium>
hmm
<Xogium>
I'm afraid this is way beyond my knowledge right now
<Xogium>
I've only just started learning maybe a month ago ;)
<Haohmaru>
don't worry, it might be a completely different thing, who knows
<Xogium>
this all started because I realized a kernel I'm trying to flash as XIP image was flashed wrong
<Xogium>
or at least, it's what verify_image said
<Xogium>
so I used this mini program to write hello world in qspi, then realized reading it back said llo world
<Xogium>
the idea is that demo program writes it ok and reads it also ok, but openocd does not, for whatever reason
<Haohmaru>
oh wait, is this using the actual "target MCU" to talk to the flash chip?
<PaulFertser>
Yes, the disco board was mentioned.
<Xogium>
so er it is just not reading it ? Or is it really missing
<PaulFertser>
Xogium: sorry, I can't really tell anything specific about this issue. If it's reproducible with current upstream OpenOCD from master branch on a discovery board then it's worth filing a ticket.
<Haohmaru>
hm, perhaps QSPI, and QSPI memory chips are not so similar to "normal" SPI memory chips, and my whole theory might go in the trash
<PaulFertser>
Xogium: are you using current master?
crabbedhaloablut has quit [Ping timeout: 276 seconds]
loki_val has quit [Ping timeout: 276 seconds]
<Xogium>
frankly mbed is tricky and it doesn't let you do -c init for some reason, I had to do it very fast when pressing reset
crabbedhaloablut has joined #openocd
<PaulFertser>
Xogium: not sure what you mean, you do not need "init" command with OpenOCD usually.
<Xogium>
hmm don't I need that to be allowed to run flash commands ?
<PaulFertser>
Xogium: init tells OpenOCD to go from configuration stage to runtime stage. Not needed for interactive usage (via telnet or gdb) as it does init automatically after startup finished.
<Xogium>
hm well I was trying to run openocd directly from command line
<PaulFertser>
"program" command does implicit init for you too
<braunr>
Xogium: oh hello o/ :)
<PaulFertser>
In any case the "init" command is not doing anything hardware-wise, it's pure logical thing inside OpenOCD.
<Xogium>
even running opeoocd -f board/stm32f769i-disco.cfg gives me 'error: init mode failed: unable to connect to the target'
<Xogium>
er openocd, that was
<PaulFertser>
Xogium: that means it's trying to connect to the board when SWD is disabled or the target is sleeping
<Xogium>
oh, heya braunr :) another long time no see person ;)
<braunr>
Xogium: another person getting his hands dirtier :)
<PaulFertser>
Xogium: you can use "reset_config srst_only connect_assert_srst" to always automatically reset it and connect before firmware start executing.
<Xogium>
well damn I don't remember what I did to read the flash again… I did so many things
<braunr>
Xogium: openocd is great, enjoy the learning process
<Xogium>
braunr: lol will sure do
<Xogium>
braunr: I'm trying to run linux XIP that is kernel and userspace on that mcu… why ? Why not ? It will be a fun challenge, if anything
<Xogium>
but currently just trying to figure out this flash stuff…
<Xogium>
PaulFertser: this reset_config, is it a command I pass with -c ?
<PaulFertser>
Xogium: you can, yes, before init.
<Xogium>
let me try
crabbedhaloablut has quit [Remote host closed the connection]
<Haohmaru>
Info : device has to be switched to 4-byte addresses
<Haohmaru>
so, check your flash chip's datasheet and see how big the address is
<Xogium>
well considering it was *info* I thought this was just a notice and opeocd did it
<Xogium>
damn why do I keep typo-ing openocd
<PaulFertser>
4-byte addresses are needed for all devices > 16 MiB.
<PaulFertser>
Not much to figure here
<PaulFertser>
Xogium: that log shows you reading from the flash. But what about writing?
<Haohmaru>
just saying *shrug*
<Xogium>
PaulFertser: with openocd or with the demo program ?
<PaulFertser>
Xogium: with openocd
<Xogium>
let me try that
<Xogium>
I've only tried to write files though, like my XIP kernel
<Xogium>
can you use openocd to arbitrarily store words in the flash ?
<PaulFertser>
Yes, with "program" or "flash write_image"
<Xogium>
ah
<Xogium>
will try that sec
<Xogium>
same
<Xogium>
or well… hard to know for sure
<Xogium>
I'll try and use the demo program to read what's written there
<Xogium>
because reading back with openocd itself is… well
<Xogium>
yes demo program reads it all goo
<Xogium>
I wrote "hello storage!" instead of "Hello Storage!" so it was printed
<Xogium>
so its… openocd not reading back correctly or ?
<Xogium>
what
<PaulFertser>
Xogium: I suggest you also do "flash info 0" on your board so that the MCU revision is revealed.
<Xogium>
ah that rev: line that is printed at the bottom
<Xogium>
it says rev is Z
<PaulFertser>
ok, that should be enough info for a bug report. So are you saying that OpenOCD is writing to flash properly but when reading misses the first two bytes?
<Xogium>
STM32F7[6|7]x - Rev: Z
<Xogium>
it… sounds like that, yeah…
<Xogium>
hm
<PaulFertser>
Xogium: hm, I do not trust "strings" there, better do "hexdump -C -n 1024" or something like that.
<Xogium>
so I just ecoed some text to hello.data, then flashed it again, openocd said wrote 15 bytes from file… Then I grabbed 256 bytes from offset 0 of bank 3 just to be dead sure
<Xogium>
it printed llo storage ! in the file
<Xogium>
but when running the demo program which first reads what's written in the flash before writing, I definitely saw the entire hello storage !
<Xogium>
ah… I can try
<Xogium>
so bad vs good in hexdump prints like this
<Xogium>
does that make sense ? I mean does it show that it doesn't read correctly ?
<PaulFertser>
I think it does, yes.
<Xogium>
I wonder why reading isn't correct but writing seems to be
<Xogium>
but… at least then it probably means I can flash my XIP kernel and XIP cramfs fs correctly…
<Haohmaru>
it's always good to verify after writing
<Xogium>
yeah
<Xogium>
which… I did but then got very confused when verify_image said nop
Simone85 has joined #openocd
<Simone85>
Hi everyone, I was talking with PaulFertser and olerem. I don't know if you guys remember my problem. I was trying to write the firmware of the microsemi smartcontrol2 from a raspberry pi. I start to play around with your suggestion using the softconsole software provided by microsemi. But this software works only on x64 architecture not ARM. So I
<Simone85>
cannot use it on the raspberry. So the next idea is to use directly the openocd sofware. Can you suggest me where to start? Where I can find the right software (with the cfg file into) and how I can write the bin file to the board. Thanks
<PaulFertser>
Simone85: iirc we suggested your demand microsemi to stop violating GPL and to release all the source code including the sources for the DLLs they link with.
<Haohmaru>
ooh
<Haohmaru>
have they modified openocd?
<Haohmaru>
or integrated it into some closed-source tool?
<olerem>
Haohmaru: yes and yes :)
<Haohmaru>
aww, straight to jail
<olerem>
Simone85: yes, you have choice, ask microsemi support to give source with changes made on openocd. Since it is GPLv2 software, they shoul provide you sources.
<olerem>
or do this + some reverse engineering
<Xogium>
so… how do I report this ? Do I have to subscribe to the openocd mailing list ?
<Haohmaru>
iirc there was this gerrit thing
<josuah>
> Since it is GPLv2 software, they shoul provide you sources.
<Haohmaru>
start off from the website, it has the links
<josuah>
great real-world example of GPLv2 at act
<josuah>
it not only solve legal situations, but also organizing the code
<josuah>
instead of having zillion of forks each implementing their own back-end, should submit upstream
<Simone85>
josuah Yes I will ask them, the funny thing is that they don't do email support just phone support....
<josuah>
Simone85: they surely use email like every company, and you might be able to find any "contact" email, it is not asking for support so maybe it will be gladly received
<josuah>
they might also be glad to know community gets involved with the bowels of the tool they use, who knows...
<josuah>
I have not gotten involved with OpenOCD insofar myself though
JakeSays has quit [Ping timeout: 256 seconds]
<Haohmaru>
Simone85 is openocd's LICENSE file there too?
<Haohmaru>
because this github project says MIT but then it also does mention that it uses binaries of opensource projects which have their own licenses
<Haohmaru>
or maybe it's "COPYING" not "LICENSE"
<olerem>
Simone85: the xpack has no related changes. it is just mainline openocd + packaging scripts