我不确定细节，因为它不是一个典型的嵌入式系统。但它是MIPS32（更具体地说，是M5150核）的一个特性。所有MIPS32核都需要一个内存管理单元来将虚拟内存映射到物理内存。在PIC32设备上，当您想到启动序列时，就会看到这一点。所有PIC32设备都在0xBFC0000万开始执行代码。这称为KSEG1，并且访问未缓存的内存，这意味着没有东西放入缓存中，无论是MZ上的L1缓存，还是MX上的picocache。在启动序列完成之后，处理器通常跳到缓存的KSEG0内存，以便获得可能的最佳执行速度。在MX设备上，有一个称为KUSEG的模式，它限制了正在执行的代码的内存映射。它应该防止访问SFRS，这将是防止访问密钥的关键。任何对硬件和密钥的访问都应该由内核处理。MZ设备具有相似的模式，但是MX使用固定映射（FMT），MZ设备有一个真正的TLB MMU，这意味着它可以进行配置。在PrP管理程序上会很好。另一种可能性是类似于LITEBSD的，它是运行在PIC32 MZ上的4.4BSD版本。这甚至可能允许将密钥存储在文件系统中，并且基于用户ID阻止对密钥的访问。
以上来自于百度翻译
以下为原文
I'm not sure about the specifics, because it is not something typically done in an embedded system. But it is a feature of the MIPS32 (and, more specifically, the M5150 core).
All MIPS32 cores require a memory management unit in order to map virtual memory to physical memory. On PIC32 devices, this is seen when you think about, say, the startup sequence. All PIC32 devices start executing code at 0xBFC0_0000. This is called KSEG1, and accesses memory uncached, meaning that nothing is put into a cache, either the L1 cache on MZ, or the picocache on MX. After the startup sequence is complete, then the processor will typically jump to cached, KSEG0 memory in order to get the best execution speed possible.
On MX devices, there is a mode called KUSEG, which limits the memory map of the code being executed. It should prevent access to the SFRs, which would be key to preventing access to the keys. Any access to the hardware and keys should be handled by the kernel.
The MZ devices have a similar mode, but where the MX uses Fixed Mapping (FMT), the MZ devices have a true TLB MMU, which means it can be configured.
Again, I'm not very familiar with the deep internals of this, which is why looking at prplHypervisor would be good. Another possibility is something like LiteBSD, which is a 4.4BSD version running on PIC32MZ. This might even allow storing the keys in a file system, and blocking the access to the keys based on a user ID.
我不确定细节，因为它不是一个典型的嵌入式系统。但它是MIPS32（更具体地说，是M5150核）的一个特性。所有MIPS32核都需要一个内存管理单元来将虚拟内存映射到物理内存。在PIC32设备上，当您想到启动序列时，就会看到这一点。所有PIC32设备都在0xBFC0000万开始执行代码。这称为KSEG1，并且访问未缓存的内存，这意味着没有东西放入缓存中，无论是MZ上的L1缓存，还是MX上的picocache。在启动序列完成之后，处理器通常跳到缓存的KSEG0内存，以便获得可能的最佳执行速度。在MX设备上，有一个称为KUSEG的模式，它限制了正在执行的代码的内存映射。它应该防止访问SFRS，这将是防止访问密钥的关键。任何对硬件和密钥的访问都应该由内核处理。MZ设备具有相似的模式，但是MX使用固定映射（FMT），MZ设备有一个真正的TLB MMU，这意味着它可以进行配置。在PrP管理程序上会很好。另一种可能性是类似于LITEBSD的，它是运行在PIC32 MZ上的4.4BSD版本。这甚至可能允许将密钥存储在文件系统中，并且基于用户ID阻止对密钥的访问。
以上来自于百度翻译
以下为原文
I'm not sure about the specifics, because it is not something typically done in an embedded system. But it is a feature of the MIPS32 (and, more specifically, the M5150 core).
All MIPS32 cores require a memory management unit in order to map virtual memory to physical memory. On PIC32 devices, this is seen when you think about, say, the startup sequence. All PIC32 devices start executing code at 0xBFC0_0000. This is called KSEG1, and accesses memory uncached, meaning that nothing is put into a cache, either the L1 cache on MZ, or the picocache on MX. After the startup sequence is complete, then the processor will typically jump to cached, KSEG0 memory in order to get the best execution speed possible.
On MX devices, there is a mode called KUSEG, which limits the memory map of the code being executed. It should prevent access to the SFRs, which would be key to preventing access to the keys. Any access to the hardware and keys should be handled by the kernel.
The MZ devices have a similar mode, but where the MX uses Fixed Mapping (FMT), the MZ devices have a true TLB MMU, which means it can be configured.
Again, I'm not very familiar with the deep internals of this, which is why looking at prplHypervisor would be good. Another possibility is something like LiteBSD, which is a 4.4BSD version running on PIC32MZ. This might even allow storing the keys in a file system, and blocking the access to the keys based on a user ID.
举报
perhaps the permission mechanisms you have mentioned :)
