compressed/head.s __setup_mmu

转载地址:https://blog.youkuaiyun.com/coldsnow33/article/details/37904799
  1. __setup_mmu: sub r3, r4, #16384 @ Page directory size,r3 = 0x20004000

  2. bic r3, r3, #0xff @ Align the pointer

  3. bic r3, r3, #0x3f00

  4. @ 这里r4中存放着内核执行地址,将16K的一级页表放在这个内核执行地址下面的16K空间里,

  5. @ 上面通过 sub r3, r4, #16384 获得16K空间后,

  6. @ 又将页表的起始地址进行16K对齐放在r3中。即ttb的低14位清零。

  7.  
  8. /*

  9. * Initialise the page tables, turning on the cacheable and bufferable

  10. * bits for the RAM area only.

  11. */

  12. mov r0, r3 @ r0 = 0x20004000

  13. mov r9, r0, lsr #18 @ r9 = 0x2000

  14. mov r9, r9, lsl #18 @ start of RAM,r9 = 0x20000000,先>>18,后<<18,就是256K对齐

  15. add r10, r9, #0x10000000 @ a reasonable RAM size,r10 = 0x30000000,0x10000000==256M

  16. @ 上面这几行把一级页表的起始地址保存在r0中,并通过r0获得一个ram起始地址(256K对齐),

  17. @ 并从这个起始地址开始的256M ram空间对应的描述符的C和B位均置”1”,

  18. @ r9和r10中存放了这段内存的起始地址和结束地址。

  19.  
  20. mov r1, #0x12 @ XN|U + section mapping

  21. @ 一级描述符的bit[1:0]为10,表示这是一个section描述符。

  22. @ bit[4]为1,

  23. @ 此时bit[8:5]均为0,选择了D0域。

  24.  
  25. orr r1, r1, #3 << 10 @ AP=11,r1 = 0xC12

  26. @ 一级描述符的AP(access permission bits) bit[11:10]为11,

  27. @ 即all access types permitted in both modes

  28. @ bit[31:20]为physical address,为0

  29.  
  30. add r2, r3, #16384 @ r2 = 0x20008000

  31. @ 一级描述符表(页表)的结束地址存放在r2中。

  32.  
  33. 1: cmp r1, r9 @ if virt > start of RAM

  34. cmphs r10, r1 @ && end of RAM > virt

  35. bic r1, r1, #0x1c @ clear XN|U + C + B

  36. orrlo r1, r1, #0x10 @ Set XN|U for non-RAM

  37. orrhs r1, r1, r6 @ set RAM section settings

  38. str r1, [r0], #4 @ 1:1 mapping

  39. add r1, r1, #1048576@ == 0x100000 = 1M

  40. teq r0, r2 @ r0==r2时,不在jump 1处执行,此时r1=4G=0

  41. bne 1b

  42. /* case 1:

  43. 1: cmp r1, r9 @ if virt > start of RAM

  44. cmphs r10, r1 @ && end of RAM > virt

  45. bic r1, r1, #0x1c @ clear XN|U + C + B

  46. orrlo r1, r1, #0x10 @ Set XN|U for non-RAM

  47. */

  48. /* case 2:

  49. 1: cmp r1, r9 @ if virt > start of RAM

  50. bic r1, r1, #0x1c @ clear XN|U + C + B

  51. orrlo r1, r1, #0x10 @ Set XN|U for non-RAM

  52. */

  53. /* case 3:

  54. 1: cmp r1, r9 @ if virt > start of RAM

  55. cmphs r10, r1 @ && end of RAM > virt

  56. bic r1, r1, #0x1c @ clear XN|U + C + B

  57. orrhs r1, r1, r6 @ set RAM section settings

  58. */

  59. @ r1 &= ~0x1c

  60.  
  61. @ 1->r1 |= 0x10

  62. @ r10 end 0x300000000

  63. @ 2->r1 |= r6,r1 |= 0x0d,在256M范围内

  64. @ r9 start 0x20000000

  65. @ 3->r1 |= 0x10

  66. @ 上面这段就是对一级描述符表(页表)的初始化,

  67. @ 首先比较这个描述符所描述的地址是否在那个256M的空间中,如果在则这个描述符对应的内存区域是 cacheable ,bufferable。

  68. @ 如果不在则noncacheable, nonbufferable。

  69. @ 然后将描述符写入一个一级描述符表(页表)的入口,并将一级描述符表(页表)入口地址加4,而指向下一个1M section的基地址。

  70. @ 如果页表入口未初始化完,则继续初始化。

  71. @ 一级描述符结构如下:

  72. @ 31 20 19 12 11 10 9 8 5 4 3 2 1 0

  73. @ 物理地址的基址 0 AP 0 域 1 C B 1 0

  74. @ || 1:1映射

  75. @ ||

  76. @ 0 <=> 0~(1M-1)

  77. @ 1 <=> 1M~(2M-1)

  78. @ 2 <=> 2M~(3M-1)

  79. @ 4095 <=> (4G-1M)~(4G-1)

  80. @ 一级描述符表(页表)的高12位是每个setcion的基地址,可以描述4096个section。

  81. @ 一级页表大小为16K,每个页表项,即描述符占4字节,刚好可以容纳4096个描述符,

  82. @ 所以这里就映射了4096*1M = 4G的空间。

  83.  
  84. /*

  85.  
  86. * If ever we are running from Flash, then we surely want the cache

  87. * to be enabled also for our execution instance... We map 2MB of it

  88. * so there is no map overlap problem for up to 1 MB compressed kernel.

  89. * If the execution is in RAM then we would only be duplicating the above.

  90. */

  91. /*

  92. */

  93. orr r1, r6, #0x04 @ ensure B is set for this

  94. orr r1, r1, #3 << 10

  95. @ 这两行是设置AP和B

  96.  
  97. mov r2, pc

  98. mov r2, r2, lsr #20

  99. orr r1, r1, r2, lsl #20

  100. @ 将当前地址1M对齐,并与r1中的内容结合形成一个描述当前指令所在section的描述符。

  101.  
  102. add r0, r3, r2, lsl #2

  103. @ r3为刚建立的一级描述符表(页表)的起始地址0x20004000。

  104. @ 将当前地址(pc)的高12位左移两位(形成14位索引)与r3中的地址

  105. @ (低14位为0)相加形成一个4字节对齐的地址

  106. @ 这个地址也在16K的一级描述符表(页表)内,r0的[31:14]为0,所以该地址<2^14=16K。

  107. @ 当前地址对应着描述符(貌似这就是一个一级描述符)在一级描述符表(页表)中的位置,这个位置之前已经初始化过了。

  108. @ 对于从ram中运行这里只是又重新设置了一次,从flash中运行,会多映射2MB

  109. @ 一级页表中索引为r2左移2位。

  110. @ r0地址结构如下:

  111. @ 31 14 13 2 1 0

  112. @ 页表基址 页表index 0 0

  113. @ r0里存储的描述符格式如下:

  114. @ 31 20 19 12 11 10 9 8 5 4 3 2 1 0

  115. @ PC高12bit 0 AP 0 域 1 C B 1 0

  116.  
  117. str r1, [r0], #4

  118. add r1, r1, #1048576

  119. str r1, [r0]

  120. @ 这里将上面形成的描述符及其连续的下一个section描述

  121. @ 写入上面4字节对齐地址处

  122.  
  123. mov pc, lr

  124. ENDPROC(__setup_mmu)

mcrne	p15, 0, r3, c2, c0, 0	@ load page table pointer,r3 = 0x20004000

MMU的段页表的虚拟地址与物理地址的转换过程

 

maixcam pro的使用文档里的API如下,那FMT_BGR888要怎么用?enum Format { FMT_RGB888 = 0, // RGBRGB...RGB, R at the lowest address FMT_BGR888, // BGRBGR...BGR, B at the lowest address FMT_RGBA8888, // RGBARGBA...RGBA, R at the lowest address FMT_BGRA8888, // BGRABGRA...BGRA, B at the lowest address FMT_RGB565, FMT_BGR565, FMT_YUV422SP, // YYY...UVUVUV...UVUV FMT_YUV422P, // YYY...UUU...VVV FMT_YVU420SP, // YYY...VUVUVU...VUVU, NV21 FMT_YUV420SP, // YYY...UVUVUV...UVUV, NV12 FMT_YVU420P, // YYY...VVV...UUU FMT_YUV420P, // YYY...UUU...VVV FMT_GRAYSCALE, FMT_BGGR6, // 6-bit Bayer format with a BGGR pattern. FMT_GBRG6, // 6-bit Bayer format with a GBRG pattern. FMT_GRBG6, // 6-bit Bayer format with a GRBG pattern. FMT_RGGB6, // 6-bit Bayer format with a RGGB pattern. FMT_BGGR8, // 8-bit Bayer format with a BGGR pattern. FMT_GBRG8, // 8-bit Bayer format with a GBRG pattern. FMT_GRBG8, // 8-bit Bayer format with a GRBG pattern. FMT_RGGB8, // 8-bit Bayer format with a RGGB pattern. FMT_BGGR10, // 10-bit Bayer format with a BGGR pattern. FMT_GBRG10, // 10-bit Bayer format with a GBRG pattern. FMT_GRBG10, // 10-bit Bayer format with a GRBG pattern. FMT_RGGB10, // 10-bit Bayer format with a RGGB pattern. FMT_BGGR12, // 12-bit Bayer format with a BGGR pattern. FMT_GBRG12, // 12-bit Bayer format with a GBRG pattern. FMT_GRBG12, // 12-bit Bayer format with a GRBG pattern. FMT_RGGB12, // 12-bit Bayer format with a RGGB pattern. FMT_UNCOMPRESSED_MAX, // compressed format below, not compressed should define upper FMT_COMPRESSED_MIN, FMT_JPEG, FMT_PNG, FMT_COMPRESSED_MAX, FMT_INVALID = 0xFF // format not valid }
最新发布
03-26
<think>好的,我现在要帮用户解答关于MaixCam Pro的API中FMT_BGR888的用法。首先,我需要确认用户的需求是什么。用户提到在文档中看到了这个枚举类型,想知道如何使用FMT_BGR888。我需要先理解这个格式的具体含义以及它在MaixCam开发中的常见应用场景。 首先,FMT_BGR888是图像格式的一种,属于像素排列方式。根据文档中的注释,BGR888是BGRBGR...的排列,每个像素占3个字节,B在最低地址。这意味着在内存中,每个像素的第一个字节是蓝色分量,接着是绿色,最后是红色。这跟常见的RGB888顺序相反,后者是红绿蓝。这一点需要特别强调,避免用户混淆。 接下来,我需要考虑用户可能的使用场景。比如,用户可能在处理摄像头捕获的图像数据,或者需要将图像显示在屏幕上,或者进行图像处理。不同的场景下,BGR格式的用途可能不同。例如,OpenCV默认使用BGR格式,所以如果用户需要将图像数据传输到OpenCV处理,使用BGR888会更方便,不需要转换颜色空间。 然后,我需要说明如何在代码中使用这个格式。通常,在初始化摄像头或者配置图像缓冲区时,需要指定图像格式。用户可能需要调用类似sensor.set_pixformat()的函数,并将参数设置为FMT_BGR888。这里要提醒用户检查具体的API函数名称,因为不同平台可能有差异。 另外,访问像素数据也是关键。用户可能需要知道如何正确解析每个字节。例如,假设有一个指向图像数据的指针data,每个像素的三个字节依次是B、G、R。需要给出示例代码,说明如何提取每个颜色分量。不过要注意,MaixCam的具体内存布局是否连续,是否有对齐的问题,这些可能需要根据实际情况调整。 还有,用户可能会遇到颜色显示不正确的问题,这时候需要检查是否格式设置正确。比如,如果误用了RGB888,颜色会错乱。这时候需要指导用户如何排查和修正。 另外,性能方面的考虑也很重要。BGR888每个像素占3字节,相比RGB565等格式,占用更多内存,但颜色精度更高。用户如果对内存或带宽敏感,可能需要权衡选择不同的格式。 最后,可能还需要提到与其他库的兼容性。比如,如果使用某些显示库或处理库,可能需要特定的格式,这时候BGR888是否适用需要确认。 总结一下,回答的结构应该是先介绍格式的定义,然后使用场景,接着具体的使用步骤和示例代码,最后是常见问题及注意事项。需要确保用户能够一步步了解如何应用这个格式,并避免常见错误。</think>在MaixCam Pro开发中,`FMT_BGR888`是图像数据格式的枚举值,用于表示像素排列方式。以下分步骤说明其用法和注意事项: --- ### **1. 格式定义** - **存储方式**:每个像素占**3字节**,按`B→G→R`顺序连续排列 - **内存布局**:例如像素序列为`B0 G0 R0 B1 G1 R1 B2 G2 R2...` - **对比RGB888**:区别仅在于颜色通道顺序相反(RGB888是`R→G→B`) --- ### **2. 典型使用场景** - **摄像头配置**:设置图像传感器输出格式 ```python # 伪代码示例(具体API以文档为准) sensor.set_pixformat(sensor.FMT_BGR888) ``` - **图像处理库兼容**:如OpenCV默认使用BGR顺序 - **屏幕显示**:适配特定显示设备的像素排布需求 --- ### **3. 数据访问示例** 假设获取到图像缓冲区指针`img_data`: ```cpp // C语言示例(假设宽高为w,h) uint8_t *ptr = img_data; for(int y=0; y<h; y++){ for(int x=0; x<w; x++){ uint8_t b = *ptr++; // 第一个字节是B分量 uint8_t g = *ptr++; // 第二个字节是G分量 uint8_t r = *ptr++; // 第三个字节是R分量 // 处理像素(r,g,b) } } ``` --- ### **4. 关键注意事项** - **内存对齐**:图像每行的字节数需按API要求对齐(常见4字节对齐) - **转换需求**:如需RGB格式,需手动交换R/B通道 - **性能影响**:相比压缩格式(如JPEG)会占用更多内存带宽 - **格式验证**:通过`sensor.get_pixformat()`确认设置是否成功 --- ### **5. 常见问题排查** - **颜色异常**:检查是否误将BGR当作RGB解析 - **内存越界**:计算缓冲区大小应为`width × height × 3`字节 - **API兼容性**:部分图像处理函数可能仅支持特定格式,需查阅文档 建议结合具体使用场景(如人脸识别/目标检测)选择最适合的像素格式。如果需要与深度学习模型配合使用,还需注意模型输入层的颜色顺序要求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值