完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
在和声文档（2.04）中，它说：“对于PIC32 MZ设备，有两个80 KB的引导闪存面板……当我建立了一个基本的引导加载程序时，链接器保留了193408个字节。这有点超过2×80kb。我记得在某个地方看到，历史上有一个16KB的块在每个面板的顶部，无法访问。但现在已经解决了吗？我dogon是添加了基于AES的Bootloader硬件解密。这意味着有可能加密图像，所以它被键入一个特定的硬件，但它的Goice使用大部分可用内存。我达到了151K以获得图书馆，优化级别为1。在2x80kb，我想我会失败，但在193K我可以。
以上来自于百度翻译 以下为原文 In the hARMony documentation ( 2.04 ) it says "For PIC32MZ devices, with two 80 KB Boot Flash panels... When i set up a basic bootloader, the linker reserves 193408 bytes.. that is somewhat more than 2 x 80KB. I remember reading somewhere that there was historically a 16KB block at the top of each panel that coud'nt be accessed. but that is now resolved? What i'm doign is adding adding AES based hardware decryption for the bootloader. this means that it is possible to encrypt an image so it is keyed to a specific bit of hardware, but its goign to use most of the avaiable memory.. I'm up to 151K to get the librarys in, with optimization level 1. AT 2x 80KB i think i'd fail but at 193K i'm be ok. Attached Image(s) 
0
|
|
相关推荐
6个回答
|
|
|
16K是在第二个引导面板的顶部，很难用一个空间访问它。使用组合的链接器脚本，将有（80k* 2）-0x100*2（配置空间）-16k＝146944。额外的可能是因为引导闪存面板之间的空间。如果您愿意经历一点头痛，可以将16k空间设置为链接器中的单独部分，并将其设置为S。具体的文件在那里，总而言之，保持配置空间，应该有163328字节可用的引导空间。
以上来自于百度翻译 以下为原文 The 16K is at the top of the second boot panel, and it would be hard to access it with one space. With the combined linker script, there would be (80K * 2) - 0x100*2 (Config Space) -16K = 146944. The extra was probably because of the space between the boot flash panels. If you're willing to go through a little headache, you could set up the 16K space as a separate section in the linker, and put specific files there. All told, keeping out of the config spaces, there should be 163328 bytes of usable boot space. |
|
|
|
|
|
谢谢拉里，我有点困惑，为什么链接器预留程序193408字节（见上面附图）。
以上来自于百度翻译 以下为原文 Thanks Larry, I'm a bit confused though, why is the linker reserved program 193408 bytes ( see the attached picture above ). |
|
|
|
|
|
它似乎是从精灵或链接器脚本中提取出来的。链接器脚本指定KSG00XPLAYTHY MEM的长度为0x2FF00—0x1000，其输出到0x2EF00（DECIMAL192256）。但是IDE似乎忽略了填充命令，它阻止了未实现的区域。
以上来自于百度翻译 以下为原文 It seems to be picking it up from the ELF or the linker script. The linker script specifies that the length of kseg0_program_mem is 0x2FF00 - 0x1000, which comes out to 0x2EF00 (decimal 192256). But the IDE seems to be ignoring the fill command, which blocks out the unimplemented area. |
|
|
|
|
|
这是否意味着有可能编译一些实际上比实际运行的更大的代码？
以上来自于百度翻译 以下为原文 Does this mean that it's possible to compile some code that will actually be bigger than what is actually possible to run? |
|
|
|
|
|
那么，我怎么才能得到这些额外的16K字节的内存呢？PosiCdEdReG3:Orth= 0x9FC14000，长度＝0x2000 -0x14000 0.FIL1: {填充（0xFF）；= OrthPoE（PlureCtEdReG3）+长度（PlureCtEdReG3）- 1；字节（0xFF）}；
以上来自于百度翻译 以下为原文 So, what do I do to get these extra 16k bytes of memory? protected_reg3 : ORIGIN = 0x9FC14000, LENGTH = 0x20000-0x14000 .fill1 : { FILL(0xFF); . = ORIGIN(protected_reg3) + LENGTH(protected_reg3) - 1; BYTE(0xFF) } > protected_reg3 20000-0x14000 |
|
|
|
|
|
有一个想法，我会看到当我编译我的代码时，有一点优化146944和lt；---字节数AVAIALBL0-不能编译1- 1516282 - 1533323 - 170412S -145244看起来像S’将勉强进入。虽然我一直在想我还能放松些什么。
以上来自于百度翻译 以下为原文 Had a bit of an idea, that i'd see what happens when i compiled my code with a bit of optimization 146944 <--- number of bytes avaialble 0 - can't compile 1 - 151628 2 - 153332 3 - 170412 s - 145284 Looks like 's' will just scrape in.. though i am keep to see what else i can loose. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5379 浏览 9 评论
2105 浏览 8 评论
2007 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3283 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2317 浏览 5 评论
888浏览 1评论
778浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
712浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
772浏览 0评论
661浏览 0评论
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
|
|
1269
评论
淘帖
1158
