Add a new flash device to the JLInkDevices database

dark1st · Jun 19th 2017, 8:38pm

Hello,

I'm playing with K82 and QSPI.

Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.

in this case I have couple of questions:
1) Is it possible to have an access to the processor via script file right before QSPI flashing?
I thought it could be SetupTarget(), but seems it isn't

If 1) - no
2) is it possible to extend JLinkDevices.xml without touching an original file?
Like create a separate JLInkDevices.xml file and add it to the jlink.dll via cmd line parameters?
I checked 10.2 paragraph and looks like it's impossible. Am I right?

if 2) - no.
Where can I find more information about Open Flashloader API?
a) which section is mandatory?
b) is it possible to use gcc for this loader creation?
c) Is it possible to provide a custom JLInkDevices.xml file to the jlink dll and which cmd line param could be used?
d) Is it possible to have a debug output in the custom loader from running gdbserver?
e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?
f) At what address does jlink load the loader code in the target?
g) if answer in f) RAM - should I specify a RAM address of my target or I can set 0 as a base address in the ELF ?

Thank you for your answers.

SEGGER - Niklas · Jun 20th 2017, 2:11pm

Hi,

1)
While "SetupTarget()" is definitely executed before the first download, "right before" and "before each" flash download can be done with "HandleBeforeFlashProg()"

HandleBeforeFlashProg() can be used with version 6.16c or higher of the J-Link software & documentation pack.
It will be documented in the near future.

Does this work for you?

Best regards,
Niklas

dark1st · Jun 20th 2017, 3:59pm

No, this stuff doesn't work.

*** J-Link V6.16c Executing PCode ***
HandleBeforeFlashProg
*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***
value = 0x00000000
*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***
read u32 from:0x400DA000
*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***
MCR = value = 0xFFFFFFFF
*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***
HandleAfterFlashProg
*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***
MCR = 0xFFFFFFFF
*** J-Link V6.16c Executing PCode ***

Looks like this callback is called BEFORE QSPI module initialization.

I need a callback which is AFTER QSPI init and BEFORE JLINKARM_MemWrite call

schema is the following: SEGGER QSPI init -> callback -> real QSPI download data

or the 2nd approach is to implement own flash loader binary (have no success here yet).

SEGGER - Niklas · Jun 20th 2017, 5:03pm

Hi Alexey,

schema is the following: SEGGER QSPI init -> callback -> real QSPI download data

This is not possible with the current version. Could you please explain what you are trying to achieve?

Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.

The QSPI flash loader should not need to care about the data format, but just program the data as it is given. Could you please elaborate?

like create a separate JLInkDevices.xml file and add it to the jlink.dll via cmd line parameters?

You can pass the command string "JLinkDevicesXMLPath <Path>" in order to specify a .xml which extends the original .xml file.
This command string is neither officially documented nor can provide support for it.

a) which section is mandatory?

This is documented in UM08001 and the wiki article: wiki.segger.com/Adding_Support_for_New_Devices

b) is it possible to use gcc for this loader creation?

In SEGGER Embedded Studio you can choose between the gcc and the llvm/clang compiler

c) Is it possible to provide a custom JLInkDevices.xml file to the jlink dll and which cmd line param could be used?

If you do not want to extend but to replace the existing .xml file, you can do so by specifying your .xml in the J-Link settings file (please refer to UM08001 for further information regarding the J-Link settings file)

d) Is it possible to have a debug output in the custom loader from running gdbserver?

If I understand correctly that the question is if the custom flash loader can be used when using J-Link GDB Server, the answer is yes.

e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?

??

f) At what address does jlink load the loader code in the target?

In the work ram area which is specified for each supported device in the J-Link software.
You can override the default work ram area by using the respective J-Link command string - please refer to UM08001 for further information.

g) if answer in f) RAM - should I specify a RAM address of my target or I can set 0 as a base address in the ELF ?

The ELF file needs to be position independent. This is done automatically when using SEGGER Embedded Studio and the provided example project.

Please do not hesitate to ask if there are further questions.

Best regards,
Niklas

dark1st · Jun 21st 2017, 12:02am

SEGGER - Niklas wrote:

Quoted
schema is the following: SEGGER QSPI init -> callback -> real QSPI download data

This is not possible with the current version. Could you please explain what you are trying to achieve?

The goal is simple, I want to run my application located in the QSPI using BOOTROM startup procedure.
The application could be loaded to the QSPI in 2 ways.
1) using jlink software
2) using sbloader functionality of BOOTROM

the way 1) is preferable because of sw debugging procedures.

SEGGER - Niklas wrote:

Quoted
Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.

The QSPI flash loader should not need to care about the data format, but just program the data as it is given. Could you please elaborate?

the issue is in the QSPI controller configuration.
before upload to QSPI jlink configures controller in the 32bit LE mode (byte ordering: B4 B3 B2 B1 B8 B7 B6 B5)
at the BOOTROM start it confifures QSPI controller in the 64bit LE mode (byte ordering: B8 B7 B6 B5 B4 B3 B2 B1)
as you can see DW1 and DW2 are swapped. in this case BOOTROM reads flash content at the address 0x68000000 and expects to have a qspi config block magic value, but it receives next 4 bytes and treated this situation as no qspi configuration present.

I can put QSPI config block into the interanl flash, but the code in QSPI will also swapped and simple doesn't work.

I can't change endianity in the chip, what's why I want to switch jlink to 64bit LE mode. I just need to write only 2 bits to the MCR register.....

SEGGER - Niklas wrote:

Quoted
d) Is it possible to have a debug output in the custom loader from running gdbserver?

If I understand correctly that the question is if the custom flash loader can be used when using J-Link GDB Server, the answer is yes.

SEGGER - Niklas wrote:

Quoted
e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?

??

Those two questions are connected to the custom flash loader debugging procedure.
I just wanted to know is there any way to make debug output from CustomFlashLoader into the gdbserver log (screen or file)

SEGGER - Niklas · Jun 21st 2017, 9:26am

Hi Alexey,

the SEGGER QSPI flash loader only works in LE32 mode. Therefore, changing the mode to LE64 before flash download will cause the flash loader to be defunct.
If changing the mode in "HandleAfterFlashProg()" does not work for you, you need to use your own flash loader.

before upload to QSPI jlink configures controller in the 32bit LE mode (byte ordering: B4 B3 B2 B1 B8 B7 B6 B5)
at the BOOTROM start it confifures QSPI controller in the 64bit LE mode (byte ordering: B8 B7 B6 B5 B4 B3 B2 B1)

I understand what LE32 and L64 do mean from a instruction or data fetch perspective, but from the flash programming perspective, i do not see the issue.
If the data file contains
Add Value
0x00 0x11
0x01 0x22
0x02 0x33
0x03 0x44
0x04 0x55
0x05 0x66
0x06 0x77
0x07 0x88

does the data read from the flash differ?
Which programm does generate the data file?

Best regards,
Niklas

dark1st · Jun 21st 2017, 11:08am

SEGGER - Niklas wrote:

the SEGGER QSPI flash loader only works in LE32 mode. Therefore, changing the mode to LE64 before flash download will cause the flash loader to be defunct.
If changing the mode in "HandleAfterFlashProg()" does not work for you, you need to use your own flash loader.

Looks like this callback is called AFTER UnInit loader function because of
*** J-Link V6.16c Executing PCode ***

HandleAfterFlashProg

*** J-Link V6.16c Executing PCode ***

*** J-Link V6.16c Executing PCode ***

MCR = 0xFFFFFFFF

*** J-Link V6.16c Executing PCode ***

I suppose thie means: "The register can't be read."

SEGGER - Niklas wrote:

I understand what LE32 and L64 do mean from a instruction or data fetch perspective, but from the flash programming perspective, i do not see the issue.
If the data file contains
Add Value
0x00 0x11
0x01 0x22
0x02 0x33
0x03 0x44
0x04 0x55
0x05 0x66
0x06 0x77
0x07 0x88

does the data read from the flash differ?
Which programm does generate the data file?

In the K82 processor there is BOOTROM which can configure QSPI flash by itself and pass an execution control to it later.
to do so I have to prepare a special structure QSPI config block.

to simplify things let imagine it has only 2 fields

struct qspi_config{
uint32_t field1; (magic: ABCD)
uint32_t fielf2; (data: 1234)
};

in case of 64LE fields are placed like "1234 ABCD"
in case of 32LE fields are palced like "ABCD 1234"

at the startup BOOTROM reads uint32_t from the structure's 0 offset and check it against magic (ABCD)
if I put data by Segger in 32LE format and BOOTROM reads it in 64LE format, then BOOTROM tries to compare 1234 against magic (ABCD).

SEGGER - Niklas · Jun 21st 2017, 12:40pm

Hi Alexey,

if I understand you correctly, the boot header / QSPI config block is always read as LE64.
Therefore, the issue can be resolved by swapping the bytes in the data file accordingly before passing it to the J-Link flash loader.

Most QSPI flashes have different available configurations / modes regarding the data format (LE32/LE64/BExx/"striping" modes with another flash, etc [..]).
Therefore, the J-Link flash loader always programs the flash in the same predictable way.

For example:
You have two QSPI flashes in "striping" mode. In order to work, the QSPI-Flashes need to be programmed as follows:

Source Code

QSPI_0: QSPI_1:
[Magic Block] [Magic Block complement]
[Configuration] [Configuration complement]
DATA_000 DATA_001
DATA_002 DATA_003
DATA_004 DATA_005
[..] [..]

The correct way to program this using the J-Link software would program QSPI_0 with:
[Magic Block]
[Configuration]
DATA_000
DATA_002
DATA_004

and then programming QSPI_1 with:

[Magic Block complement]
[Configuration complement]
DATA_001
DATA_003
DATA_005

On first sight, this might seem more complicated that passing program the QSPIs with the following data to J-Link and expecting that J-Link handles to rest automatically,:

DATA_000
DATA_001
DATA_002
DATA_003
DATA_004
DATA_005

but it makes things easier and more transparent to the User.
Problems regarding the 2nd way of doing the QSPI progamming are for example:
- Where and how does the user specify the [Configuration]?
- Is the current QSPI controller configuration the configuration that is used afterwards?
- In stand-alone mode / mass production, what should be done if the QSPI controller configuration differs from the prepared one?
- It would be necessary the have a user interface for each QSPI
- We would need to adapt the J-Link flash loader to be able to alter the data file for any QSPI configuration on the fly. This would also slow down programming speeds
- [...]

Best regards,
Niklas

dark1st · Jun 21st 2017, 3:32pm

BOOTROM always uses 64LE, this is a hardware implementation of BOOTROM.

BOOTROM is able to program the flash by itself using communication procedure with a host.
Looks like the 64LE mode is forever.

Segger is used only for debug purposes and the convenient way is just to pass "load a.elf' command to the gdb.
The rest is handled by jlink.
In this case application can't be run without jlink (dword swap issue).

Doing a special dance with dword swap in the code/data sections in the ELF file is a bit strange

The goal is to have XIP from QSPI of whole application.

So as a resume it would be great to have more flexible QSPI configuration from the user side or have more detailed
instructions about custom flash loader in the doc.

PS. right now I'm trying to bring up my custom loader for the qspi.
PPS. no need to invent a supporting a lot of modes inside jlink.
any mode is handled by qspi controller.

Two QSPI chips in parallel mode or 1 QSPI chip in a single mode the PAGE WRITE command is the same, but the data layout is different.
Verify command will be different also.

dark1st · Jun 21st 2017, 8:38pm

The endianity issue has been solved using a Custom Flash Loader.

dark1st · Jun 21st 2017, 11:09pm

In case of several flash records (FlashBankInfo) in the JLinkDevices.xml file is it possible to specify a particular record for use using script of monitor command?

Source Code

Share