ti-sdk-evm-am335x-05.07 uboot分析(MLO跳转到u-boot之前)

川长思鸟来 2022-08-13 11:56 172阅读 0赞

\--------------------------------------------------------------------------------

**                         ROM CODE如何从MMC启动**

\--------------------------------------------------------------------------------

![SouthEast][]

![SouthEast 1][]

![SouthEast 2][]

ROM code将boot parameters的结构体指针通过R0寄存器传递给MLO，在start.s的reset部分，第一句指令就是：

bl save\_boot\_params.

5.07版本中相关代码比较复杂，而7.00中就相对简单：

![Image 1][]

就是将R0的数据存储到r1所指的地址中，仅仅存储了一个指针就返回了。

\-------------------------------------------------------------------------

**Start.s  Start**

\-------------------------------------------------------------------------

位于arch/arm/cpu/armv7/start.s

![SouthEast 3][]

上电直接跳到reset异常处理例程

![SouthEast 4][]

调用save\_boot\_params，保存boot参数，不详述。continue...

![SouthEast 5][]

cpy\_clk\_code是将DPLL的代码拷贝到SRAM中，暂不述。

cpu\_init\_crit只在SPL阶段会被调用，用于setup important registers and memory timing.

![SouthEast 6][]

接着调用lowlevel\_init函数，位于arch/arm/cpu/armv7/omap-common/lowlevel\_init.s文件。

从名字可以看出，该文件用于底层的初始化。

\--------------------------------------------------------------------------------

lowlevel\_init Start（lowlevel\_init.s）

\--------------------------------------------------------------------------------

![SouthEast 7][]

![SouthEast 8][]

这里首先建立一个临时的栈，用于运行接下来c程序s\_init。其中LOW\_LEVEL\_SRAM\_STACK定义在asm/arch/omap.h文件里面。

![SouthEast 9][]

而0x4030B7FC位于MPU的L3 OCMC0区域。

![SouthEast 10][]

调用的函数s\_init，位于board/ti/am335x/evm.c下。

在s\_init中有几步很关键

![SouthEast 11][]

1、  preloader\_console\_init()用于初始化串口，调用serial\_init(),该函数位于common/serial.c文件里面。

![SouthEast 12][]

serial\_init()函数首先检查当前有没有串口，显然没有，就只能用 默认串口 default\_serial\_console结构。该结构定义在drivers/serial/serial.c中。

![SouthEast 13][]

其中CONFIG\_CONS\_INDEX宏定义在include/configs/am335x\_evm.h,定义为1表示使用UART0口。

这块是移植时候需要注意的地方，否则调试u-boot时候在默认的串口上不会打印信息。

![SouthEast 14][]

**2、** enable\_i2c0\_pin\_mux() i2c\_init()以及read\_eeprom(),这三个函数主要适用于TI公司AM335x相关的板子。

这一系列板子上面都有EEPROM并且存储了板子的信息，read\_eeprom用于读取相关信息。

s\_init  **C**ontinue...

![SouthEast 15][]

定义变量is\_ddr3用于选择初始化的对象，这也是移植时候需要注意的地方。

\--------------------------------------------------------------------------------

lowlevel\_init End（lowlevel\_init.s）

\--------------------------------------------------------------------------------

call\_board\_init\_f Start（start.s）

\--------------------------------------------------------------------------------

Back to start.s

调用完cpu\_init\_crit后,start.s会继续，接着会调用board\_init\_f()，在调用之前会在内部SRAM中设立栈指针，

这样才能调用函数，因为函数调用需要入栈的操作。

![SouthEast 16][]

1、栈指针值CONFIG\_SYS\_INIT\_SP\_ADDR

start.s又包含 config.h 文件（位于am335x/include/config.h，am335x是编译时候生成的，Makefile将与目标板相关的文件集中在此处）

![Image 1][]

config.h文件内容：

![SouthEast 17][]

在configs/am335x\_evm.h中定义了CONFIG\_SYS\_INIT\_SP\_ADDR:

![SouthEast 18][]

即CONFIG\_SYS\_INIT\_SP\_ADDR = SRAM0\_START + SRAM0\_SIZE - GENERATED\_GBL\_DATA\_SIZE

其中 SRAM0\_START定义在hardware.h中，进入后可知 SRAM0\_START = 0x402F0400，正是Memory Map中SRAM internel的首地址。

![SouthEast 19][]

![SouthEast 20][]

SRAM0\_SIZE定义在cpu.h中，进入后可知 SRAM0\_SIZE = 0x1B400，这个SIZE一直将SRAM延伸到OCMC0里面，结束地址为0x4030B800。

![SouthEast 21][]

![SouthEast 22][]

GENERATED\_GBL\_DATA\_SIZE定义在generic-asm-offset.h（asm-offset.h包含此头文件）中，值为128。

这个size的空间是用于存储global\_data结构的数据，存储空间以16字节对齐（这个并未证明，因为代码里面没有在任何地方提到将全局变量指针指向此地）。

![SouthEast 23][]

总结一下 ，到这一步，在MPU的内部OCMC0区设置栈底SP = 0x4030B800 - 128 =  0x4030B780 ，并在栈底上面存储分配128 Bytes空间用于存储全局数据。

2、MLO重定位

board\_init\_f函数位于arch/arm/cpu/armv7/omap-common/spl.c。该函数唯一做的事情就是向relocate\_code

函数传入三个参数，然后程序流程又回到start.s文件。

![SouthEast 24][]

在board\_init\_f()函数调用start.s中的relocate\_code函数，这里实现重定位（实现机理可以百度之），

[http://blog.csdn.net/zsy2020314/article/details/9824035][http_blog.csdn.net_zsy2020314_article_details_9824035]  这个解释不错

[http://blog.sina.com.cn/s/blog\_7656589b0100ys1l.html][http_blog.sina.com.cn_s_blog_7656589b0100ys1l.html]  这个解释不错

重定位后，后面的puts不会运行了，因为relocate\_code不会返回。见下图。

![SouthEast 25][]

\--------------------------------------------------------------------------------

**relocate\_code Start（start.s） **

\--------------------------------------------------------------------------------

relocate\_code的代码如下：

/\*  
\* void relocate\_code (addr\_sp, gd, addr\_moni)  
\*  
\* This "function" ***does not return***, instead it continues in RAM  
\* after relocating the monitor code.  
\*  
\*/  
     .globl     relocate\_code  
relocate\_code:  
     mov     r4, r0     /\* save addr\_sp \*/  
     mov     r5, r1     /\* save addr of gd \*/  
     mov     r6, r2     /\* save addr of destination \*/  
  
     /\* Set up the stack                                  \*/  
stack\_setup:  
     mov     sp, r4  
  
     adr     r0, \_start  
     cmp     r0, r6  
     moveq     r9, \#0          /\* no relocation. relocation offset(r9) = 0 \*/  
     beq     clear\_bss          /\* skip relocation \*/  
     mov     r1, r6               /\* r1 <- scratch for copy\_loop \*/  
     ldr     r3, \_image\_copy\_end\_ofs  
     add     r2, r0, r3          /\* r2 <- source end address         \*/  
  
copy\_loop:  
     ldmia     r0!, \{r9-r10\}          /\* copy from source address \[r0\]    \*/  
     stmia     r1!, \{r9-r10\}          /\* copy to   target address \[r1\]    \*/  
     cmp     r0, r2               /\* until source end address \[r2\]    \*/  
     blo     copy\_loop  
  
\#ifndef CONFIG\_SPL\_BUILD  
     /\*  
     \* fix .rel.dyn relocations  
     \*/  
     ldr     r0, \_TEXT\_BASE          /\* r0 <- Text base \*/  
     sub     r9, r6, r0          /\* r9 <- relocation offset \*/  
     ldr     r10, \_dynsym\_start\_ofs     /\* r10 <- sym table ofs \*/  
     add     r10, r10, r0          /\* r10 <- sym table in FLASH \*/  
     ldr     r2, \_rel\_dyn\_start\_ofs     /\* r2 <- rel dyn start ofs \*/  
     add     r2, r2, r0          /\* r2 <- rel dyn start in FLASH \*/  
     ldr     r3, \_rel\_dyn\_end\_ofs     /\* r3 <- rel dyn end ofs \*/  
     add     r3, r3, r0          /\* r3 <- rel dyn end in FLASH \*/  
fixloop:  
     ldr     r0, \[r2\]          /\* r0 <- location to fix up, IN FLASH! \*/  
     add     r0, r0, r9          /\* r0 <- location to fix up in RAM \*/  
     ldr     r1, \[r2, \#4\]  
     and     r7, r1, \#0xff  
     cmp     r7, \#23               /\* relative fixup? \*/  
     beq     fixrel  
     cmp     r7, \#2               /\* absolute fixup? \*/  
     beq     fixabs  
     /\* ignore unknown type of fixup \*/  
     b     fixnext  
fixabs:  
     /\* absolute fix: set location to (offset) symbol value \*/  
     mov     r1, r1, LSR \#4          /\* r1 <- symbol index in .dynsym \*/  
     add     r1, r10, r1          /\* r1 <- address of symbol in table \*/  
     ldr     r1, \[r1, \#4\]          /\* r1 <- symbol value \*/  
     add     r1, r1, r9          /\* r1 <- relocated sym addr \*/  
     b     fixnext  
fixrel:  
     /\* relative fix: increase location by offset \*/  
     ldr     r1, \[r0\]  
     add     r1, r1, r9  
fixnext:  
     str     r1, \[r0\]  
     add     r2, r2, \#8          /\* each rel.dyn entry is 8 bytes \*/  
     cmp     r2, r3  
     blo     fixloop  
     b     clear\_bss  
\_rel\_dyn\_start\_ofs:  
     .word \_\_rel\_dyn\_start - \_start  
\_rel\_dyn\_end\_ofs:  
     .word \_\_rel\_dyn\_end - \_start  
\_dynsym\_start\_ofs:  
     .word \_\_dynsym\_start - \_start  
  
\#endif     /\* \#ifndef CONFIG\_SPL\_BUILD \*/  
  
clear\_bss:  
\#ifdef CONFIG\_SPL\_BUILD  
     /\* No relocation for SPL \*/  
     ldr     r0, =\_\_bss\_start  
     ldr     r1, =\_\_bss\_end\_\_  
\#else  
     ldr     r0, \_bss\_start\_ofs  
     ldr     r1, \_bss\_end\_ofs  
     mov     r4, r6               /\* reloc addr \*/  
     add     r0, r0, r4  
     add     r1, r1, r4  
\#endif  
     mov     r2, \#0x00000000          /\* clear                   \*/  
  
clbss\_l:str     r2, \[r0\]          /\* clear loop...              \*/  
     add     r0, r0, \#4  
     cmp     r0, r1  
     bne     clbss\_l  
  
/\*  
\* We are done. Do not return, instead branch to second part of board  
\* initialization, now running from RAM.  
\*/  
jump\_2\_ram:  
/\*  
\* If I-cache is enabled invalidate it  
\*/  
\#ifndef CONFIG\_SYS\_ICACHE\_OFF  
     mcr     p15, 0, r0, c7, c5, 0     @ invalidate icache  
     mcr     p15, 0, r0, c7, c10, 4     @ DSB  
     mcr     p15, 0, r0, c7, c5, 4     @ ISB  
\#endif  
     ldr     r0, \_board\_init\_r\_ofs  
     adr     r1, \_start  
     add     lr, r0, r1  
     add     lr, lr, r9  
     /\* setup parameters for board\_init\_r \*/  
     mov     r0, r5          /\* gd\_t \*/  
     mov     r1, r6          /\* dest\_addr \*/  
     /\* jump to it ... \*/  
     mov     pc, lr  
  
\_board\_init\_r\_ofs:  
     .word board\_init\_r - \_start

从代码的最后可以看出来，最后mov pc,lr,是跳到重定位后的 board\_init\_r函数处。

代码还是那段代码，只是在内存中的位置变化了。

再回到board\_init\_f中调用relocate\_code函数，传入三个参数：

relocate\_code(CONFIG\_SPL\_STACK, &g\_data, CONFIG\_SPL\_TEXT\_BASE);

第一个参数是栈指针：CONFIG\_SPL\_STACK

第二个参数是全局数据结构指针：&g\_data

第三个参数是重定位的目的地址：CONFIG\_SPL\_TEX\_BASE

relocate\_code的代码是用汇编书写的，这里要提到的是C参数如何传递给汇编语言的。这里必须要提到ABI和EABI，

ABI是Application Binary Interface的缩写，跟API很类似。但ABI是比API更贴近硬件的一层接口，它规定的

是二进制代码之间的调用规则。

我们知道API是与机器硬件平台无关的接口，如熟悉的printf函数，不同的库的实现可能是不同的，但是它们的接口名称

与参数类型都是一样的。ABI比API的要求更严格，它要求在寄存器级别遵守同样的接口规范，如函数调用的参数传递规则，

寄存器、堆栈的使用方式等。编译器被要求遵守同样的ABI规范，这样不同编译器编译出来的库（相同硬件）才能被别的

编译器使用。

EABI是使用与嵌入式场合的应用二进制接口。这里就简单提一下：函数调用时，传递的参数如果都小于32bit则使用

R0-R3传递参数，参数个数超出4个则使用STACK传递，因此为了代码的效率，程序员应该尽量保证将函数的参数个数限制

在4个以下。

对于CONFIG\_SPL\_STACK,是LOW\_LEVEL\_SRAM\_STACK的宏定义。

![SouthEast 26][]

另外am335x\_evm.h还包含hardware.h

![SouthEast 27][]

hardware.h包含omap.h

![SouthEast 28][]

在omap.h中有LOW\_LEVEL\_SRAM\_STACK的宏定义，这个宏定义和前文提到调用s\_init函数前的建立栈底是一样的。

![SouthEast 29][]

由于栈生长的方向是向下的，所以栈底必须设置为高地址处，这个地址已经快接近OCMC0的底部。

![SouthEast 30][]

对于 CONFIG\_SPL\_TEXT\_BASE，正是MPU内部SRAM的起始地址。

![SouthEast 31][]

\--------------------------------------------------------------------------------

**relocate\_code End** **（start.s）**

\--------------------------------------------------------------------------------

总结一下：从打印信息看，我们的板子的stack生长方向是递减的。

有一点很疑惑的是：在调用board\_init\_f之前，SP设置为0x4030B780，进入board\_init\_f后调用

relocate\_code，传入的SP地址参数为0x4030B7FC，SP往上面移动了，这是为什呢？因为重定位后是不会从

relocate\_code函数返回的，所以board\_init\_f的入栈参数会被抹掉但无所谓，但是能不能将这两次的SP设置成一样的呢？

(PS: TI-SDK-AM335X-EVM-07.00中堆栈的设置没有让人confused的地方了)

![SouthEast 32][]

\--------------------------------------------------------------------------------

call\_board\_init\_f End（start.s）

\--------------------------------------------------------------------------------

board\_init\_f函数调用relocate\_code，该函数实现代码的搬迁。从下面的图中可以看到：

![SouthEast 33][]

\_start处于内存位置：0x402F0400

在relocate\_code中，

relocate\_code:  
     mov     r4, r0     /\* save addr\_sp \*/  
     mov     r5, r1     /\* save addr of gd \*/  
     mov     r6, r2     /\* save addr of destination \*/

stack\_setup:  
     mov     sp, r4

adr     r0, \_start  
     cmp     r0, r6  
     moveq     r9, \#0          /\* no relocation. relocation offset(r9) = 0 \*/  
     beq     clear\_bss          /\* skip relocation \*/  
     mov     r1, r6               /\* r1 <- scratch for copy\_loop \*/  
     ldr     r3, \_image\_copy\_end\_ofs  
     add     r2, r0, r3          /\* r2 <- source end address         \*/

将\_start加载到r0中，与r6比较，而r6是由r2传递过来的目标地址CONFIG\_SPL\_TEXT\_BASE=0x402F0400。

因此会执行beq clear\_bss处，即copy\_loop的代码不会执行。

在代码里面加入宏开关，重新编译后依然能执行，证实了这个想法：

MLO阶段不会将自己copy到SRAM中，copy动作应该是由ROM Code实现的。

另外一个证明就是，ti-sdk-07.00版本的u-boot代码中明确了没有在MLO阶段调用relocate\_code，仅仅在u-boot阶段调用。

![SouthEast 34][]

\-------------------------------------------------------------------------

**Start.s  End**

\-------------------------------------------------------------------------

\--------------------------------------------------------------------------------

board\_init\_r Start（start.s）

\--------------------------------------------------------------------------------

relocate\_code结束的时候，跳到board\_init\_r函数处，该函数位于arch/arm/cpu/armv7/omap-common/spl.c。

该函数主要初始化内存、各个外设：

mem\_malloc\_init()

timer\_init()

i2c\_init()

spl\_board\_init()

然后选择从那个外设加载image。我们调试的时候从SD卡加载u-boot的image，所以关注spl\_mmc\_load\_image函数。

\--------------------------------------------------------------------------------

**spl\_mmc\_load\_image Start（board\_init\_r） **

\--------------------------------------------------------------------------------

首先取得boot\_device的序号，这个序号是定义在boot\_params结构体的第三个成员项

![SouthEast 35][]

omap\_boot\_device函数定义在arch/arm/cpu/armv7/omap-common/boot-common.c中。

![SouthEast 36][]

结构体omap\_boot\_parameters定义在 ![SouthEast 37][]，这个定义与最开始

时候的Booting Parameters Structure是一致的。

![SouthEast 38][]

将boot\_device和boot\_params的地址都打印出来，如下图所示：

![SouthEast 39][]

可以看到boot device是8，对应的是MMC/SD port 0设备，boot\_params结构体的地址是0x40303990，位于L3 0CMC0存储区，很显然这个地址是由连接器分配的，位于“Downloaded Image”区域。

而在spl\_mmc\_load\_image中最关键的部分是，

![SouthEast 40][]

将boot\_mode打印出来，2对应MMCSD\_MODE\_FAT模式。

![SouthEast 41][]

另外，由于代码的增加，这儿可以看到boot\_params结构体的地址变成了0x403039B8。

而mmc\_load\_image\_fat中最重要的代码就是解析header和读出image。

![SouthEast 42][]

spl\_parse\_image\_header将header的中信息解析出来放在结构体spl\_image里面，file\_fat\_read函数将image读到spl\_image.load\_addr所指向的缓冲区。

\--------------------------------------------------------------------------------

**spl\_mmc\_load\_image End（board\_init\_r） **

\--------------------------------------------------------------------------------

spl\_image是很重要的一个结构体，将其打印出来看看有什么。

![SouthEast 43][]

spl\_image的地址已经到了0x8000,0000，这已经是Externel SDRAM的首地址了。那么谁安排spl\_image的地址的？

搜索一番，发现spl\_image处于.bss区域，即未初始化区域，map里面将其放在0x8000000地址。

![SouthEast 44][]

回过头来查看arch/arm/cpu/armv7/omap-common/u-boot-spl.lds链接脚本文件，可以看到：

![SouthEast 45][]

![SouthEast 46][]

也就是说.bss段被指向sdram存储区域，map文件则显示链接器将spl\_image安排在第一个。 不知道这种安排是否是有意为之？（后来从7.00上面证明并非刻意安排，而是ld的行为） 从map看，似乎是谁离lds文件更近谁出现在map的最前面，这种安排是有些道理的，一定程度上能解释为什么spl\_image在map上处于第一个。

![SouthEast 47][]

从spl\_image.os的数值可以得出，下一步就是执行jump\_to\_image\_no\_args()函数。

![SouthEast 48][]

该函数首先typedef一个新类型，该类型是入参和返回值均为void的函数指针类型，并且用这个类型定义一个变量image\_entry，将spl\_image.entry\_point赋值给它，最后执行这个函数，从汇编的角度看，就是将spl\_image.entry\_point赋值给PC，下一步就是跳转到SDRAM的0x80100000执行。

\--------------------------------------------------------------------------------

board\_init\_r End（start.s）

\--------------------------------------------------------------------------------

MLO阶段结束。

[SouthEast]: /images/20220810/e1e43318ff8648489692293bf750f747.png
[SouthEast 1]: /images/20220810/7486f34ae1ad49309ee2632efc7b3631.png
[SouthEast 2]: /images/20220810/6e8b8284e7af404dba08d66b135fb31a.png
[Image 1]: 
[SouthEast 3]: /images/20220810/a63f5f93ff1243b98e7e275209e2f674.png
[SouthEast 4]: /images/20220810/0524c1f535c7400c94220d1439960020.png
[SouthEast 5]: /images/20220810/d0bd416d0f294dbca0869ff1b6fe3fd9.png
[SouthEast 6]: /images/20220810/06d4f308dc66465b8f9284889c0c2831.png
[SouthEast 7]: /images/20220810/5c5a4733ff4342cfa3d9ee9503913ea5.png
[SouthEast 8]: /images/20220810/ede1f6e1fd4d4c2a99264cd41c1052b2.png
[SouthEast 9]: /images/20220810/9d07f896a2d343bdabefa4a6a08d0c44.png
[SouthEast 10]: /images/20220810/cec299001dbf424282ca199542e3061b.png
[SouthEast 11]: /images/20220810/0648ee0a0ada4ca2af5bc09ad275fe93.png
[SouthEast 12]: /images/20220810/32c14693e77a4f1c882d80bda52d28f5.png
[SouthEast 13]: /images/20220810/79b5ac9531484a91a845f99deed0d4e8.png
[SouthEast 14]: /images/20220810/69e34ee5428b4d3bb7f4c0a46190ccf2.png
[SouthEast 15]: /images/20220810/7d56ca2e674c4d49a0b6794ccfec797d.png
[SouthEast 16]: /images/20220810/7fa5fe735b174741b7211a0a3ff44b1f.png
[SouthEast 17]: /images/20220810/1f06ebecb2004828bab94943d7c4027b.png
[SouthEast 18]: /images/20220810/9902f4a67d4b468daa3c9d6a949329b8.png
[SouthEast 19]: /images/20220810/1a4455441406434ba561a75df6c8fc0e.png
[SouthEast 20]: /images/20220810/2f44b3fde6044a658395816fb33d7577.png
[SouthEast 21]: /images/20220810/88efbb9789a2446598bd9d97a9cde156.png
[SouthEast 22]: /images/20220810/a0fc8111228b4b4083a54bb5bbcb8c66.png
[SouthEast 23]: /images/20220810/b60dbabb71b54b24b40166edbed277e2.png
[SouthEast 24]: /images/20220810/cd2ad11c3a2a47a48cd93b9b030eaef3.png
[http_blog.csdn.net_zsy2020314_article_details_9824035]: http://blog.csdn.net/zsy2020314/article/details/9824035
[http_blog.sina.com.cn_s_blog_7656589b0100ys1l.html]: http://blog.sina.com.cn/s/blog_7656589b0100ys1l.html
[SouthEast 25]: /images/20220810/5c9c494574ca4a3aace45c94b8586e2b.png
[SouthEast 26]: /images/20220810/cac8c547d4944631bec4837480ce4d0b.png
[SouthEast 27]: /images/20220810/f5f6faf4dde94742b97a58e1c3921165.png
[SouthEast 28]: /images/20220810/d2fb15e629c34aedb79a0f9496ae1ec6.png
[SouthEast 29]: /images/20220810/138122cde3eb40c485730b5faaeb8324.png
[SouthEast 30]: /images/20220810/4aba71bf418c45c1934c573a9f9f0bb7.png
[SouthEast 31]: /images/20220810/3b599edf8ae7462e9eb02b8d11b72d16.png
[SouthEast 32]: /images/20220810/961f007c7e674099887140237165e7fa.png
[SouthEast 33]: /images/20220810/b395a2be148b41cb9d07018947e17e81.png
[SouthEast 34]: /images/20220810/182b5994fa774dbaab0f353e218552ab.png
[SouthEast 35]: /images/20220810/c06a085278464ec9a23d0fa241d5de63.png
[SouthEast 36]: /images/20220810/452aaef3a38a4d42b4beb3ed43f927fd.png
[SouthEast 37]: /images/20220810/61f00ce339d741fba4563dad3e4cedb6.png
[SouthEast 38]: /images/20220810/ca17959b964645358cab6fcc40eb418d.png
[SouthEast 39]: /images/20220810/c0d42aa6227749d2929269604174e30f.png
[SouthEast 40]: /images/20220810/7af28483e31e476ab2c0ae8a208c979a.png
[SouthEast 41]: /images/20220810/ddab621731d4420e8db98dfbe9f709c0.png
[SouthEast 42]: /images/20220810/e813757b89924785a04f0cc44eadbb38.png
[SouthEast 43]: /images/20220810/b97221ff007b44d7ac1a013c7cc67485.png
[SouthEast 44]: /images/20220810/287db6038c474afa9e27c388694d0ac8.png
[SouthEast 45]: /images/20220810/f42b192667a74ac4925ec6e51953f96a.png
[SouthEast 46]: /images/20220810/9da0120ef3bd4d5abd6b3c33bd410239.png
[SouthEast 47]: /images/20220810/165a70d94c894346a0b49c06f68c427e.png
[SouthEast 48]: /images/20220810/531342f079c345568a8515f3d0f9d85d.png