Part Number: AM6421
Other Parts Discussed in Thread: SYSCONFIG
Hello,
I have the following questions from a customer about the AM64x devices.
SYSFW Questions:
1. Absent any messages waiting in message queue and any currently in processing, can we expect the DMSC to still be processing something in the background? Or will it continuously poll the message queues until a message is found?
2. Assuming firewalls and resources are configured as expected, it is possible that a processor can inadvertently affect the execution status or memory that is does not have access to?
3. Can SYSFW be reset without doing a full SoC reset? Would MCU domain have to do this?
4. After most system initialization is complete (firewall setup, interrupts configured, memory mapped, applications booted) what other critical functions are required for continued system operation that depend on SYSFW?
General Questions:
1. Where are the expected register bit field value combinations associated with DRR controller configuration and generated by DDR SYSCONFIG. Though the DDR configuration tool generates these values, there is no documentation stating what the legal values are. Even in the TRM specific register section.
1a. Generated from DDR config tool
1b. 
1c. TRM page 7601
2. It is mentioned in the release notes and MCU documentation that CCS 20 should be used. But the documentation instructions are very clearly given in CCS 12. Please clarify what version of CCS should be used. (see below image)
3. The TRM still mentions the "legacy" boot flow information stating that SYSFW must be loaded by the SBL. Does a new TRM release occur in synchronization of a new SYSFW release? When can we expect a new TRM? It makes it more challenging to be a source of truth when it still has outdated information. (see TRM pg 86 below)
AM64x MCU+ SDK: Bootflow Migration Guide
4. We noticed that the SK-AM64 and AM64EVM are in low quantity and in backlog. We also noticed the DDR memory chips that are used on these boards are both obsolete or EOL and now longer sold by Mouser and DigiKey. Not sure if this is the reason why, but if it is the case, will we be expecting a new revision and updated documentation for the evaluation boards?
4a. MT40A1G16KD-062E IT:E (Obsolete on Mouser, Digikey)
4b. T53E1G16D1FW-046 WT:A (Obsolete/EOL/Restricted Availability on Mouser, DigiKey)
5. For the firewall, it looks like there is a "security handoff". Would it be possible for us to configure the boards such that we hand off security to the R5_0_0 core and then from there the R5 would have full control of most of the firewalls (via direct firewall register access)? Is that a bad idea?
6. What is the nuance between resource and firewall management? Since most resources/peripherals are memory-mapped, it seems conceptually like managing resources is effectively managing access to the memory map, which is also what the firewalls do.
7. It is not clear exactly what is configured in the default board configuration blob and what is configured afterward in the SBL. Part of the confusion is likely that the documentation seems to be a mix of a legacy process and the current process.
