Hi Shawn, On 8/28/21 8:03 AM, Shawn Guo wrote:
[..] Or you think these are all misusing of PT_LOAD? Sorry, I hardly believe your understanding on PT_LOAD matches the reality. Instead, I'm inclined to agree with Bjorn's comment.
Agreed, PT_LOAD does not imply _external_ loading at all, merely whether it has to be copied to the final memory region. That's my misunderstanding, even after quoting the documentation.
This external loading is merely a qcom implementation detail AFAIK, and solely detected by the source boundaries (p_offset - p_offset+p_filesz) residing outside the .mdt file.
Quote: "I would expect that PT_LOAD denotes that the segment should be loaded into the final firmware region and that the hash segment would be PT_NULL regardless of being part of the .mdt, single .mbn or a separate .bNN segment." The only part that doesn't hold is "the hash segment would be PT_NULL". But the point is that PT_LOAD doesn't mean the segment should be loaded externally (from .bNN file).
Yes, this is strange. Why would the .mdt request the hash segment to be loaded to firmware memory when it's filtered out anyway? Are we supposed to filter it out?
[..] I will send v2. However there will be no code change but just commit log update based on all these discussion. Thanks!
Sounds good - glad we could have this discussion to get to the bottom of this and conclude that removing this check is the right approach without any side-effects, including a detailed justification in the commit-message.
- Marijn
