13:59 <Willmish> PaulFertser: Hi again, I have managed to bring the patch up to date and fix all merge conflicts, and after a few days break sitting back to trying to fix the flashing driver. At the moment I have an issue of flash_probe call always returning 0x0 for the device ID rather than the actual device ID. Here is my fork on GH with up to date changes:

13:59 <Willmish> https://github.com/Willmish/openocd/blob/eoss3_flash_patch/src/flash/nor/eoss3.c

13:59 <Willmish> Currently trying to replicate the SPI write/read process step by step to figure out what is wrong based on EOS S3 docs page 317 : https://www.quicklogic.com/wp-content/uploads/2020/06/QL-S3-Technical-Reference-Manual-Vol-1.pdf , however with no luck yet. Any pointers where I might better undestand how to perform device ID reading properly? (need to

13:59 <Willmish> send 0x9F command over SPI to the flash device, and get its response)

13:59 <Willmish> (resending as I got disconnected and cant see my msg in logs)

14:01 <PaulFertser> Willmish: hey

14:02 <PaulFertser> Willmish: can you check with an oscilloscope or LA if the SPI communication happens at all? Probably the SPI peripheral is disabled or its clock is not enabled or something like that?

14:03 <PaulFertser> Willmish: btw, OpenOCD has some generic code for SPI NOR flash devices, you might want to refactor to use that.

14:04 <PaulFertser> Willmish: "git grep flash_devices" will show you how the other drivers do it.

14:10 <Willmish> PaulFertser: I do not have an oscilloscope on me, but might go to a university lab to check it (although the flash device doesnt have any exposed paths/legs so dont know if its even possible to connect to it that way). But from my understanding the SPI peripheral is working fine as status registers are correctly being modified? (status register

14:10 <Willmish> flag for TX FIFIO when its full is 1 and eventually is set to 0, so assuming it is being transferred somewhere?)

14:12 <Willmish> But will take a look at the other devices

14:24 <PaulFertser> Willmish: oh, I kinda hoped this bus is easy to probe

14:25 <PaulFertser> Willmish: probably the pin muxing is wrong then?

14:25 <PaulFertser> Willmish: do your device have some other SPI bus that's easier to probe? You can pretend the flash is there on another bus to see if the driver manages to do any real exchanges there at all.

14:41 <Willmish> PaulFertser: AFAIK it doesn't, I will start by looking at how whatever I am currently doing differs from what QuickLogic implemented in their FreeRTOS bootloader (https://github.com/QuickLogic-Corp/qorc-sdk/blob/master/qt_apps/qt_bootloader/src/program_flash.c#LL164C17-L164C17) and how it differs from one of the boards that also does flash device

14:41 <Willmish> recognition (uses the "flash_devices" array : https://github.com/Willmish/openocd/blob/eoss3_flash_patch/src/flash/nor/ath79.c

14:41 <Willmish> If I don't see any progress there, then will try to do what you've suggested and try to somehow connect to some SPI bus on the board, although I do not have a lot of experience with such hardware debugging

14:56 <PaulFertser> Willmish: just seeing if there's any signal on the CLK line should be enough for starters.

14:56 <PaulFertser> Willmish: I suspect wrong pinmuxing

16:56 <kraiskil> when would I want to use the command "gdb_memory_map disable"? I found it in an old openocd.cfg file of mine, and now it caused a heap of problems.

16:57 <kraiskil> Reading the docs, I don't see any reason to use it...

18:18 <Willmish> PaulFertser: in that case will need to wait until Wednesday, as I don't have an oscilloscope with me (all I have is a multimeter but that won;t tell me anything about the signal). Would plugging in to the external SPI CLK be enough?

18:23 <PaulFertser> kraiskil: not sure, it wasn't ever useful to me

18:24 <PaulFertser> Willmish: no, it all needs to be in sync.

18:25 <PaulFertser> Willmish: probably you can re-check the init to make sure the pins are switched to SPI mode and clocking is enabled etc.