一、Armv8-A地址翻译Armv8-A使用一个虚拟内存系统，其中代码所使用的地址（虚拟地址）被转换为内存系统所使用的物理地址。此转换由被称为内存管理单元（MMU）的处理器的一部分执行。Arm体系结构中的mmu使用存储在内存中的转换表将虚拟地址转换为物理地址。MMU将在必要时自动读取翻译表，此过程被称为表行走。MMU的一个重要功能是使系统能够运行多个任务，作为在自己的私有虚拟内存空间中的独立程序运行。它们不需要了解系统的物理内存映射，即硬件所使用的地址，或了解可能同时执行的其他程序。您可以为每个程序使用相同的虚拟内存地址空间。您还可以使用连续的虚拟内存映射，即使物理内存是碎片化的。此虚拟地址空间与系统中内存的实际物理映射分开。您可以编写、编译和链接应用程序，以在虚拟内存空间中运行。单个系统中的不同处理器和设备可能具有不同的虚拟和物理地址映射。特权软件，如操作系统，通过编程使MMU在这两个内存视图之间进行转换，如下图所示。要做到这一点，虚拟内存系统中的硬件必须提供地址转换，这是由处理器发出的虚拟地址到主内存中的物理地址的转换。
虚拟地址是您在内存中放置代码时以及编译器和链接器所使用的 ...
ARMv8体系架构
未读严格来说，中断是说软件执行流程的东西，但是，在arm术语中，统称为异常。异常是需要特权软件（异常处理程序）执行某些操作以确保系统顺利运行的条件或系统事件。每种异常类型都有一个异常处理程序。一旦处理完异常，特权软件就会让内核准备好恢复它在处理异常之前所做的任何事情。下面介绍了几种异常：
Interrupt 一般有两种，分为irq和fiq。fiq的优先级高于IRQ，这两种异常通常都与内核上的输入引脚相关。假设中断未被禁用，外部硬件断言了一个中断请求并在当前指令完成执行时触发相应的异常类型（irq or fiq）,fiq和irq对core来说都是物理信号，当被断言时，如果内核当前已启用，则会发生相应的异常。在几乎所有系统上，各种中断源都使用中断控制器连接。中断控制器对中断进行仲裁并确定其优先级，进而提供串行化的单个中断信号，然后将其连接到内核的FIQ或IRQ信号。由于IRQ和FIQ中断的发生在任何时间，与内核正在执行的软件没有直接关系，因此它们被归类为异步异常 。
Abort 在指令获取失败（指令中止）或数据访问失败（数据中止）时生成中止。它可来源于内存访问错误时的外部内存系统（可能 ...
问题现象售后出现一台无法开机的机器，现象是卡白米
问题分析set_frame 0x00后没有ackset_frame 0x03后没有ack
同时kernel启动3s后，stick驱动一直反复打印日志，从3s到34s之间几乎全部是stick驱动读写的报错日志
34s的时候发现misc分区没有挂载，init发起了reboot的指令
而misc分区没有挂载的原因就是cpu一直被stick占用，导致mountFstab无法挂载分区。检查读写函数，发现如下异常这是一个嵌套循环，也就是100*10=1000次的反复调用spinlock的接口获取和释放锁。
问题原因此问题的原因在于spinlock的频繁获取和释放，导致CPU被占用，性能下降导致无法开机。
下面总结一下自旋锁被频繁申请释放的风险和问题：在Linux内核中，自旋锁（spinlock）是一种用于保护共享资源的锁机制，主要用于短时间的锁定操作，不会引起线程调度。频繁地启用（enable）和禁用（disable）自旋锁可能带来以下风险和问题：
性能开销：每次获取和释放自旋锁都会涉及内存屏障和CPU指令，以确保内存操作的顺序性和锁 ...
一、问题背景https://wayawbott0.f.mioffice.cn/sheets/shtk4qr1GSkUjvozmsj0OWi0tGe测试版本：V816.0.24.8.26.UGUCNXM稳定版挂测MTBF报出大量的空指针引用的报错
二、问题分析2.1 dump解析使用离线解析工具linux ramdump parser解析dump，打开dmesg_tz.txt
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051[51222.768793][T13540] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038[51222.768825][T13540] Mem abort info:[51222.768836][T13540] ESR = 0x96000007[51222.768848][T13540] EC = 0 ...
一、问题现象老化测试时出现黑屏现象，9/12：今天已经确认的现象
使用9-11的版本 72台机器出现27 个黑屏，其中25个为USB问题引起的dump（2个是电量低关机），通过LOG分析是在老化45次重启测试的时候出问题（45次重启1个半小时），9-11版本带了高通的等待probe完成 wait_for_device_probe
出现黑屏的问题是使用33瓦的充电器出现问题，5V2A 的充电器没有问题（上海没有出现黑屏的原因就是因为使用的是5V2A）
老化充电100的原因也和充电器有关，使用33瓦的时候设置了停充概率有复冲的情况已经找到原因，今天给出解决方式
9/13 验证结果：使用0912的版本验证50PCS，出现1带黑屏，原因是低电量关机，电量在正常范围（60~80之间），出现adb 端口没有0912 临时版本修改项
解决方案将在报错的函数前加空指针return出去和加log–吴超
修改了老化电量管控节点问题—曾祥源
9/14 验证结果：验证老化黑屏的2个版本工厂端：加一个判断获取到的设备只是否为空—–24/50 黑屏上海：报错的 ...
ARMv8体系架构
未读
c5b1c9d87331a45001ba9b8dd4d3824dcdb0440640a1963744c70c84d2bb34ef65ca301f946b70afa03f6b6b445de8617a34bb4217e837eab40a1b88e9303250390b091b9bbf6e1309c45b2203e4e3bbcc08974ad6e4ff8c5f6e5b87e856eca9e5f05648e97ef27e5587f2e9d5a849efb4a77f22c0202152ebf4d3ac4b34b933097c90e79c62c1e7ad3d0f5f50e923bf680d5674d57cfab26ec142403a3e4e2f9e782c771d4c57e4974565064cfdbe6238da5adf0f0ab8c488fdf8138ec895b715c14387fc16ac8cfb73f74c257da3c22f6379f2037cac3f6f49841ae0f2b7aab96ac4cf9907a3c47d2aad3cfd6c365fb23f73e9eb7104dbe ...
一、问题现象从导出的/dev/logfs中的UefiLog日志中存在乱码，且日志不全
C3F项目正常、C3F2项目异常
二、问题分析
从现象来看存在的乱码其实是‘0’，所以有可能是因为初始化的log buffer过大 大于实际的log buffer size，导致初始化的补0 打印了出来
数据乱序
1234line 88: B - 24877312 - Bootup frequency set to 1555200下一句日志跑到了第一行line 1 : 5937 - do_ddr_training, Delta
下面从以上两个怀疑点验证问题
2.1 怀疑XBL log buffer size设置异常
2.1.1 follow C3F项目从C3F2的代码来看，当前有问题的版本关于XBL log buffer的初始化 走在了静态分配的函数里，我check了C3F项目的代码，发现C3F走在了132行里面，故更改逻辑让代码走入132行
https://gerrit.odm.mioffice.cn/c/platform/vendor/qcom/non-hlos/+/ ...
