10:46 <karlp> sometimes you're limited by the flash, sometimes by transport speeds.

11:59 <gamiee> karlp: yeah. i am happy that i am limited with transport speeds right now

13:03 <karlp> are you working on boufallo stuff? might be because the "flash" is sram fronted internally anyway?

13:28 <gamiee> karlp: yes, currently on bl702, but will work on others as well.

13:28 <gamiee> and the devkit I have does have external winbond SPI Flash.

13:28 <gamiee> I did not tried flashing internal Flash yet (procedure is same), that will be task of upcoming days :P

15:37 <gamiee> yay! Reading integrated flash works too!

15:37 <gamiee> Atleast in this BL706, in the chip is 'mac 25l8005' (ID 0x001420c2)

15:50 <gamiee> Although, I am encountering one issue. The flash base is specified as 0x2300_0000. In reality, this is base address of eXecute In Place (XIP) peripheral, which also features option to specify offset address. So in reality, in SPI Flash, on 0x0000 is boot header, and on 0x2000 is code. But execution address is 0x2300_0000, in boot header is 0x2000 offset specified. The question is, when gdb's "load" function is used to write elf, I guess it tries to write it

15:50 <gamiee> into area according to LMA. Although I am really not sure how to do this. Please, does anyone have any suggestions please?

16:00 <PaulFertser> gamiee: probably like target/rp2040.cfg: flash bank $_CHIPNAME.alias virtual 0x10000000 0 0 0 $_TARGETNAME_1 $_FLASHNAME

16:00 <gamiee> ooooh rp2040 does that???? going to take look on it, thanks!!!

16:05 <gamiee> PaulFertser: but uhh, I am bit confused how it works :(

16:06 <PaulFertser> gamiee: I guess you can define aliases for the flash memory, then they will be mentioned in the memory map and GDB will be using them as flash.

16:09 <gamiee> PaulFertser: oh okay. But I am not quite sure how I can use this to solve my problem :( The problem is, that the XIP offset is specified in Boot Header, so basically, OpenOCD/GDB doesn't know where to actually load the firmware, unless it parses boot header.

16:09 <gamiee> I got an idea, that app flash offset will be specified as parameter to flash bank driver command.

16:10 <gamiee> Thus if driver will see writes into XIP area, it will write it to the flash + offset. But it's.... not sure if it's best idea.

16:12 <PaulFertser> gamiee: I do not exactly follow, sorry. The real mapping between the addresses used by code while executing and the flash can be arbitrarily specified by the code itself?

16:15 <gamiee> PaulFertser: sorry for confusion. When BootROM wants to launch user app in Flash, it firstly reads data from Flash offset 0x0, which contains Boot Header. This boot header contains "flash_offset" field, which specifies, where is the code is. Then BootROM takes this offset, and configures XIP, that it should use offset 0x2000. That means, on 0x2300_0000, there are contents from 0x2000. (This feature is used also for A/B firmwares, so you can have same

16:15 <gamiee> firmware on two locations in Flash, and just use different flash_offset configuration in XIP).

16:19 <gamiee> So, since the VMA and LMA of the code in .elf is specified to 0x2300_0000, my driver flashes it to Flash offset 0x0. But on 0x0, there must be boot header, and according boot header, the code must be (most usually it is) on Flash offset 0x2000.

16:33 <PaulFertser> gamiee: what does readelf say about program headers for such an ELF?

16:36 <PaulFertser> gamiee: I know regular MCU ELFs which contain some initial values for the globals are loaded properly to flash addresses despite the fact the code expects all those variables at a different address when running.

17:24 <gamiee> PaulFertser : I am just working on it now, I think I got it to do exactly what I need

17:27 <gamiee> https://paste.debian.net/hidden/2d1b2943/

17:57 <gamiee> https://paste.debian.net/hidden/67644590/ I solved it like this, and I don't need to modify anything in OpenOCD, yay!

18:46 <PaulFertser> gamiee: cool! Yes, that's what I implied, that something needs to be fixed in the linker script.