logger: Enable LDC and FW compatibility check by default

[ktrzcinx]

By default user should use compatible files but forcing no check also should be possible.

[plbossart]

What would be the results if the two firmware binary and ldc are not aligned?
the trace 'mostly' works but cannot be trusted?
Is there really an actual need for disabling this check?

[ktrzcinx]

What would be the results if the two firmware binary and ldc are not aligned?
the trace 'mostly' works but cannot be trusted?

It depends how much both of them are misaligned, it may be just point wrong line in a trace source location (when a few lines in source code will be added / deleted) or when some trace will be added/deleted, then it may be complete mess-up.

Is there really an actual need for disabling this check?

In general, this option is usable when there is no access to version file and for developers for fast FW validation after some quick-fix,

From #3195 (review):

My dictionary proliferation and usability concern is not about full time SOF developers like you. It's about infrequent users. For instance a kernel developer who doesn't know much about SOF, reports a bug and receives a slightly different firmware file from someone else for a quick test. ~@marc-hb

[plbossart]

What would be the results if the two firmware binary and ldc are not aligned?
the trace 'mostly' works but cannot be trusted?

It depends how much both of them are misaligned, it may be just point wrong line in a trace source location (when a few lines in source code will be added / deleted) or when some trace will be added/deleted, then it may be complete mess-up.

Is there really an actual need for disabling this check?

In general, this option is usable when there is no access to version file and for developers for fast FW validation after some quick-fix,

From #3195 (review):

My dictionary proliferation and usability concern is not about full time SOF developers like you. It's about infrequent users. For instance a kernel developer who doesn't know much about SOF, reports a bug and receives a slightly different firmware file from someone else for a quick test. ~@marc-hb

ok, so not for someone like me...

[lgirdwood]

@ktrzcinx btw what is the lookup mechanism used in LDC files ? are we using the binary address as a lookup into the LDC string table ? It may be more consistent if we were to hash the dir, file, line and use this lookup as this would survive binary changes.

[lgirdwood]

Even better would be to hash dir + file and trace string.

[ktrzcinx]

@ktrzcinx btw what is the lookup mechanism used in LDC files ?

each tr_xxx() is forwarded to _log_message() macro. There static part of trace (lvl, format, line_idx, file name, component_class deprecated, number of arguments) is moved to .static_log. lvl section (.static_log_entries segment) and address of this static entry (plus parameters, component and pipe id) is used in runtime, passed through DMA and parsed by logger.

.static_log_entries is saved in LDC file as it is + some header. So changing any trace line_idx will change LDC file content, but traces layout should looks the same, addidng/delete trace will shuffle LDC content.

hash used to verification LDC and FW compatibility is calculated from source code, so any FW change will be reported.

[lgirdwood]

@ktrzcinx thanks for the info ! I guess this is something we could look at over the long term so that tooling can be more robust for non technical users.

[lgirdwood]

SOFCI TEST

[lgirdwood]

@ktrzcinx think we are good to merge once rebased.

[ktrzcinx]

@lgirdwood already rebased and tested by CI