海思学习随笔

 

 

  • lsusb 命令会扫描系统的 USB 总线，不仅会列出连接到当前 Linux 系统的所有外部 USB 设备，还会列出系统内部的 USB 设备和 USB 控制器
  • udev 是 Linux 系统中用于动态管理设备节点和设备事件的守护进程（不是一个长期运行的进程，不能用 ps 或 top 看，但是udev 的主要工作是由 systemd-udevd 服务来完成的，所以可以systemctl status systemd-udevd 或者 ps aux | grep systemd-udevd 或者查看日志：journalctl -u systemd-udevd
     ），添加udev规则:
    • 在 /etc/udev/rules.d/ 目录下创建一个新的规则文件，例如 51-android.rules
    • 在文件中添加以下内容，以确保 ADB 能够正确识别你的设备。假设你的设备的 Vendor ID 是 0x1D6B，Product ID 是 0x0001 : SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{idProduct}=="0001", MODE="0666", GROUP="plugdev"
    • 重新加载 udev 规则以使更改生效: sudo udevadm control --reload-rules && sudo udevadm trigger
  • 查看 usb 设备的权限(看其它用户能不能访问)： ls -l /dev/bus/usb/

 

  • 显示系统当前所有的内核参数及其值：sysctl -a  // 查看特定的：sysctl kernel.sysrq
  • 从指定的配置文件中读取内核参数并应用：sysctl -p <file>// sysctl -p /etc/sysctl.conf
  • 临时设置一个参数: sysctl -w net.ipv4.igmp_max_memberships=20

 

 

  • 文档里地址空间烧录，解释:
    • nand dump 0 0x2  // uboot 下查看数据，查看从地址0 开始 0x2 结束的这段地址

 

 

  • ubi.mtd=2 root=ubi0:rootfs 解读
    • 了解
      • UBI（Universal Block I/O）是一种专为 NAND Flash 设计的文件系统层，它旨在克服 NAND Flash 的物理限制，如坏块管理和磨损均衡。UBI 为上层文件系统提供了一个块设备接口，使文件系统可以像使用普通硬盘那样使用 NAND Flash。
      • MTD（Memory Technology Devices）是 Linux 内核中的一组驱动程序，用于支持各种类型的非易失性存储器，包括 NAND Flash 和 NOR Flash。MTD 驱动程序提供了与硬件交互的抽象层，使得上层软件可以使用统一的接口来访问不同类型的存储器。
      • UBI 构建在 MTD 之上，利用 MTD 驱动程序来访问底层的 NAND Flash。在 UBI 中，NAND Flash 被划分为多个称为“物理 eraseblock”的单元，而 UBI 为这些单元提供了一个逻辑视图，称为“逻辑 eraseblock”。UBI 进一步将这些逻辑 eraseblock 组合成“volumes”（卷）
    • ubi.mtd=2
      • 指定 UBI 使用的 MTD 设备编号为 2。(MTD 设备编号是 MTD 驱动程序为系统中的每个非易失性存储器设备分配的一个唯一标识号)
      • 在这个例子中，编号 2 的 MTD 设备是 NAND Flash，UBI 将在这个设备上运行
    • root=ubi0:rootfs
      • 指定根文件系统的位置
      • ubi0 是 UBI 卷的名称，它表示在 MTD 设备 2 上创建的第一个 UBI 卷
      • rootfs 是 UBI 卷内的文件系统名称，即根文件系统
      • UBI 卷 ubi0 包含一个名为 rootfs 的文件系统，该文件系统将被用作系统的根文件系统
    • UBI 卷和 MTD 设备的关系
      • UBI 卷:
        • UBI 卷是在 MTD 设备上创建的一个逻辑容器，用于存储文件系统。
        • 每个 UBI 卷都有一个唯一的名称，例如 ubi0
        • UBI 卷内部可以包含一个或多个文件系统
        • UBI 卷的大小和配置是由 UBI 管理器决定的，它可以自动管理坏块、磨损均衡等
      • MTD 设备
        • MTD 设备是 UBI 卷所在的物理 NAND Flash 存储器。
        • MTD 设备编号（例如 2）用于标识哪个 NAND Flash 设备被用作 UBI 卷的基础。
    • 总结：ubi0是在编号为2的flash上面划分的卷，里面包含了rootfs
    • 分区和卷：
      • 分区是物理NAND Flash上划分的区域，通常用来区分不同的数据类型或用途，例如boot分区、kernel分区、rootfs分区
      • 卷 (Volume): 卷是在分区之上的一层逻辑抽象，通常用于文件系统。在使用UBI的情况下，卷是在UBI设备上创建的，它可以包含UBIFS文件系统
      • 分区 -> 卷(其中ubi卷是借用内核驱动mtd访问的flash， ubi提供磨损均衡、坏块管理等功能) -> 文件系统(用于组织和管理文件及目录的一种逻辑结构。在嵌入式系统中，常见的文件系统有YAFFS2、JFFS2、UBIFS等, UBIFS是一种专为UBI设计的文件系统，它利用UBI提供的功能来实现高效的文件存储和管理)

    

 

  • 查看flash的类型和大小:
    • uboot 模式执行 printenv 
      1. 执行printenv（这些变量可以由用户定义和修改，也可以由 U-Boot 自动设置)
  # printenv
  autorun=1
  baudrate=115200
    # mem=512m 是说系统 RAM(一般也就是ddr) 是512M。 flash的空间要把 mtdparts 里的值加起来
    # console=ttyAMA0,115200: ttyAMA0 表示串口设备名称、115200 表示串口通信的波特率
    # clk_ignore_unused 告诉内核忽略未使用的时钟，有助于减少功耗
    # ubi.mtd=2： 指定 UBI（Universal Block I/O）设备的 MTD 设备编号，2 表示 MTD 设备编号为 2
    # root=ubi0:rootfs 指定根文件系统的挂载点,ubi0 表示 UBI 卷的名称,rootfs 表示 UBI 卷内的文件系统名称
    # rootfstype=ubifs 指定根文件系统的类型为UBIFS 文件系统
  bootargs=mem=512M console=ttyAMA0,115200 clk_ignore_unused ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw mtdparts=nand:2M(boot),12M(kernel),32M(rootfs),64M(usrfs),8M(dss),-(reserve)
    #fxw bootcmd 环境变量定义了 U-Boot 启动时执行的一系列命令: 
      # nand read 0x50000000 0x200000 0xc00000 :从 NAND Flash 的地址 0x200000(内核起始地址) 开始读取 0xC00000(12MB，内核大小) 的数据到 RAM 的地址 0x50000000
      # bootm 0x50000000: 启动位于 RAM 地址 0x50000000 的内核或加载程序
  bootcmd=nand read 0x50000000 0x200000 0xc00000;bootm 0x50000000
  bootdelay=1
  bootfile="uImage"
  camName=HD Camera
  charEncode=1
  chnNum=1
  cmdPort=8080
  companyAddr=
  companyName=
  coreVer=16843009
  devFeature=515
  devType=0
  diNum=2
  doNum=1
  ethDHCP=0
  ethact=gmac0
  ethaddr=28:B7:7C:8F:17:01
  gatewayip=192.168.1.1
  httpPort=80
  hwVer=33630005
  ipaddr=192.168.1.162
  irFilter=2
  irManage=0
  irSignal=0
  ircutPwl=0
  istPort=9660
  ivsType=0
  language=0
  nand_erasesize=20000
  nand_oobsize=40
  nand_writesize=800
  netCardNum=2
  netmask=255.255.255.0
  p2pType=1
  paramMagic=1217463299
  passwd=admin
  pppoeEnable=0
  productDate=1356912000
  productName=fxw s d
  protocol=7864327
  rs232Num=1
  rs485Num=2
  rtmpPort=1935
  rtspPort=554
  sensorType=53
  serialId=
  skipCheckSns=1
  stand=0
  stderr=serial
  stdin=serial
  stdout=serial
  swVer=151069184
  thirdPfType=0
  user=admin
  ver=U-Boot 2010.06 (Nov 05 2019 - 14:00:16)
  verify=n
  viCfgMask=0
  wifigateway=192.168.1.2
  wifiip=192.168.1.163
  wifimac=00:11:22:33:44:56
  wifinetmask=255.255.255.0
  zoom=20
  
  Environment size: 1200/262140 bytes

  

  • RAM、ddr、ROM、flash
    • RAM：
      • 易失性存储器，可读可写
      • 相当于 Windows 的内存
    • ddr:
      • 是 RAM 的一种类型，提供高速数据传输
      • 相当于 Windows 的 RAM
    • ROM：
      • 传统意义上的 ROM 是非易失性只读存储器
      • 现代的 ROM 类型（如 EEPROM）可写。
      • 主要用于存储固件（如 BIOS）和引导加载程序等不需要频繁更新的数据。
      • 相当于 Windows 的 BIOS/UEFI
    • flash：
      • 非易失性存储器，可读可写
      • 相当于window的硬盘

 

cat /proc/994/status (查看994进程的详细状态) 
 
~ # cat /proc/994/status
Name:   webs  # 进程名
Umask:  0022  # 文件创建掩码
State:  S (sleeping)  # 进程状态（如运行、睡眠、停止等）
Tgid:   994  # 线程组ID（也就是进程ID）
Ngid:   0  # 网络组ID
Pid:    994 # 进程ID
PPid:   1 # 父进程ID
TracerPid:      0   # 正在跟踪该进程的进程ID
Uid:    0       0       0       0  # 用户ID信息
Gid:    0       0       0       0  # 组ID信息
FDSize: 64  # 文件描述符表的大小
Groups:   # 进程所属的补充组ID列表
# Ns*: 命名空间信息
NStgid: 994
NSpid:  994
NSpgid: 878
NSsid:  878
# VmPeak, VmSize, VmLck, VmPin, VmHWM, VmRSS: 虚拟内存统计信息
VmPeak:     3196 kB
VmSize:     3196 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       376 kB
VmRSS:       376 kB
# RssAnon, RssFile, RssShmem: 常驻内存统计信息
RssAnon:              56 kB
RssFile:             180 kB
RssShmem:            140 kB
# VmData, VmStk, VmExe, VmLib, VmPTE: 不同类型的内存使用情况
VmData:      492 kB
VmStk:       132 kB
VmExe:       380 kB
VmLib:      1964 kB
VmPTE:        36 kB
VmSwap:        0 kB #交换空间使用情况
CoreDumping:    0 #是否正在转储核心文件
Threads:        1 # 线程数
SigQ:   0/1817
# SigQ, SigPnd, ShdPnd, SigBlk, SigIgn, SigCgt: 信号相关信息
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180004002
# CapInh, CapPrm, CapEff, CapBnd, CapAmb: 进程的能力集
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0 # NoNewPrivs: 是否禁止新权限
Speculation_Store_Bypass:       thread vulnerable # 关于推测执行和存储旁路漏洞的状态
Cpus_allowed:   f # 进程被允许运行的CPU掩码
Cpus_allowed_list:      0-3 # 允许运行的CPU列表
voluntary_ctxt_switches:        3621 # 自愿上下文切换的次数
nonvoluntary_ctxt_switches:     4 # 非自愿上下文切换的次数

 

dmesg 可以 查看开机信息、控制环形缓冲区，比如清空缓冲区 (-c 选项) 或者设置日志级别 (-n 选项)

 

cat /proc/cpuinfo ( /proc 由内核动态生成的，用于暴露系统内核和进程的信息，在/proc目录下，每个进程也都有一个对应的目录) 
# cat /proc/cpuinfo
processor(处理器)       : 0 
BogoMIPS(衡量处理器性能的指标)        : 48.00
Features(特征)        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp # "fp"表示浮点运算，"asimd"表示SIMD（单指令多数据流）扩展，"aes"表示AES加密指令，等等
CPU implementer（实施者[爱普蓝特]） : 0x41  # 0x41是十六进制表示，转换成十进制是65，这代表ARM公司（"A"的ASCII码是65）
CPU architecture(结构): 8 # 8表示这是ARMv8架构的处理器
CPU variant(变体[歪润得])     : 0x2 # 0x2表示这是一个变体版本2的CPU
CPU part(部分[泡特])        : 0xd05 # 0xd05是具体的CPU型号标识，这通常与制造商和具体型号相关联。在这个例子中，这看起来像是一个海思（HiSilicon）的处理器，因为海思的处理器型号常常以"d0"开头
CPU revision(修订[瑞v显])    : 0 #0表示这是CPU设计的第0次修订

processor       : 1
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 2
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

processor       : 3
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x2
CPU part        : 0xd05
CPU revision    : 0

 

btools (读取内存对应的值... ) 
btools 是华为海思（Hisilicon）SoC（System on Chip）上用于硬件调试和测试的一套工具集。
这类工具通常在开发板或嵌入式系统上使用，为工程师提供底层硬件访问的能力，比如内存读写、I2C和SSP（串行外设接口）设备的交互等

~ # btools -h
-h    print help msg
-i    install board tools
-u    uninstall board tools
-V    print version
------------------------------------------------------
 bspmd      : memory display (8bit) # 读8位内存地址对应的值，结果自然也是8位，一个字节如 90
 bspmd.l    : memory display (32bit) # 读32内存地址对应的值，结果自然也是32位
 bspmm      : memory modify  # 软件里面执行：system("bspmm 0x0102F012C 0x1201"); // 修改内存0x0102F012C地址的值为 0x1201
 bspddrs    : ddr statistic
 i2c_read   : i2c device read
 i2c_write  : i2c device read
 ssp_read   : ssp device read
 ssp_write  : ssp device read

 

在加载 ko 的时候，为什么 /dev 里面会多了个设备 
 1.当在 Linux 系统中使用 insmod 命令加载一个内核模块（通常是一个 .ko 文件），这个模块可能包含驱动程序代码，用于管理和控制特定的硬件设备。
    加载模块到内核后，如果模块需要用户空间程序能够访问硬件设备，它通常会创建一个或多个设备节点在 /dev 目录下。
    
2.这些设备节点是内核与用户空间之间交互的接口。它们允许用户空间的程序通过文件 I/O 操作（如读、写、打开、关闭）来访问硬件设备。
    创建设备节点是必要的，因为用户空间的程序不能直接与硬件通信，它们需要通过内核提供的接口来进行。
    
3.设备节点通常是一个字符设备或块设备，它们通过主设备号和次设备号来标识。
    主设备号用于识别设备类型和驱动程序，而次设备号则用于区分同一类设备的不同实例。
    当模块加载时，它会向内核注册一个或多个设备号，然后使用 mknod 系统调用或通过 udev 规则来创建设备节点。
    
4.以下是一些常见的情况：
  1. 模块自行创建设备节点：
     某些模块在其初始化代码中会直接调用 mknod 系统调用来创建设备节点。例如，一个简单的字符设备驱动可能会这样做。
  2.udev 规则自动创建设备节点：
     当模块加载并注册设备号后，udev 守护进程可能会监听到这个事件，并根据预定义的规则自动创建设备节点。这通常用于更复杂的设备，如 USB 设备、网络设备等。
  3. 动态创建设备节点：
     在某些情况下，设备节点并不是在模块加载时立即创建的，而是当设备插入系统时才创建。例如，USB 设备的驱动程序通常会在设备插入后由 udev 规则创建相应的设备节点。
     
所以，当你加载一个内核模块后，如果在 /dev 目录下看到了一个新的设备节点，这通常意味着该模块已经成功加载，并为用户空间提供了访问硬件设备的接口。如果模块没有创建设备节点，这可能意味着该模块不需要用户空间的直接访问，或者模块加载时遇到了问题。

 

BusyBox是一个集成了一百多个最常用Linux命令和工具的软件，它提供了一个相对完备的嵌入式Linux系统所需要的工具集

uboot 就是 Bootloader 的一种

镜像就是一个硬盘里的所有内容的打包(根据需要可能多一点，可能少一点)， 而fastboot镜像里面一般是 Bootloader、内核(可能还有文件系统)

 

bootROM 
 
bootROM（也称为Boot Read-Only Memory）是一种固化在芯片内部的只读存储器（ROM 内存）。其里面的代码在芯片制造完成后就无法更改

1.作用与功能
    bootROM中包含了一些预先编写好的代码，这些代码负责完成系统启动前的基本初始化和配置。
    它能够初始化时钟、GPIO控制器、中断控制器、存储设备（如SD卡、NAND Flash、SPI Flash等）等硬件资源
    检测启动设备，并从启动设备中加载引导程序（如U-Boot）到DDR（Dynamic Random-Access Memory，动态随机存取存储器）中
    
2.与U-Boot的关系：
    在启动过程中，bootROM首先被加载执行，它会从存储设备中加载U-Boot引导程序到DDR中。
    加载完U-Boot后，bootROM的初始化操作就完成了，接下来的工作由U-Boot接管，进行更详细的硬件初始化和操作系统内核的加载
    
    
3.与BurnTool工具的交互：
    在U-Boot烧写过程中，BurnTool工具首先与bootROM进行交互。
    工具将DDR参数传送到bootROM，这是为了后续能够正确地初始化DDR，并将U-Boot传输到DDR中。

4.烧写流程：
    BurnTool工具开始烧写后，与bootROM进行交互，并传送DDR参数。
    bootROM使用这些参数初始化DDR。
    接着，工具将U-Boot传输到DDR中。
    当U-Boot在DDR中启动完成后，工具开始与U-Boot进行交互，发送烧写命令，将DDR中的U-Boot烧写到Flash对应地址中。

 

.dts、.dtsi 

Linux内核启动时，内核通过解析设备树可以动态地配置硬件设备，加载对应的驱动程序，并建立设备之间的关联关系。
.dts文件经过编译后会生成.dtb（Device Tree Blob）文件，这是一种二进制格式的设备树表示形式，可以被Linux内核加载并解析。

dtsi 文件是设备树源码包含文件，主要用于提取多个.dts文件中共同的部分，以减少代码的冗余，一个SoC可能有多个不同的电路板，
而每个电路板拥有一个.dts文件，这些.dts文件之间势必会存在许多共同部分。.dtsi文件的作用就是将这些共同部分提炼出来，供不同的.dts文件共同使用

dtsi文件的使用类似于C语言的头文件，在.dts文件中通过include语句来包含.dtsi文件。
这样，多个.dts文件就可以共享同一个.dtsi文件中定义的节点和属性，从而减少了代码的重复
posted @ 2024-06-17 09:42  封兴旺  阅读(57)  评论(0)  编辑  收藏  举报

联系方式: 18274305123(微信同号)