全志在线开发者论坛

chenlinfei

@whycan 劳动人民的智慧

chenlinfei

@whycan 是的

chenlinfei

试了下最新的V2.0代码，支持多个视频，但是跑3个视频跑不起来。

chenlinfei

刚测试，V2.0版本的SDK，这个问题还是存在。

chenlinfei

tplayerdemo xxx.avi yyy.avi
会出现3个视频在播放，1/2屏幕是xxx，剩下的两个1/4屏幕是yyy。
这大概率是个BUG，如下图：

824640ff-00fd-432d-9822-fc2a5b97e8b0-lADPJxRxQXEayHXNC9DND8A_4032_3024.jpg

chenlinfei

@whycan 找到个方法我试了可行：

首先安装qemu and binfmt

sudo apt update
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
每次重新启动WSL并希望i386支持时，您都需要重新激活此功能：

sudo service binfmt-support start
2. 接下来启用i386体系结构和package

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install cpp-9:i386
sudo apt install gcc:i386
至此，就可以运行之前的32位binary了。

设置开机启动

vim /etc/myinit.sh
sudo service binfmt-support start

chenlinfei

@whycan 帮忙搞个静态编译的版本？我看了下这个fsbuild的依赖库都是纯C库，text也不大，静态编译的elf文件应该不会太大，未来的技术支持工作量也可以小点。

chenlinfei

@whycan 在 fsbuild有问题中说：

/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /

这些32位的库，昨天在百度上找找方法，已经都安装了一遍了，但仍然是有问题。

chenlinfei

@chenlinfei
我用的是 WSL，

cat /etc/os-release

NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

chenlinfei

同问：
32位库都已经安装好了，还是有以下错误

/home/chenlf/sourcecode/d1/tina-d1-open/out/host/bin/fsbuild
bash: /home/chenlf/sourcecode/d1/tina-d1-open/out/host/bin/fsbuild: cannot execute binary file: Exec format error

chenlinfei

@bedrock 在同一个屏幕的3个区域同时播放。

chenlinfei

从help看，可以通知播放2个视频，我们需求要播放3个视频，是否可以支持？

#notice:we can play two file use the following command,for example the video or audio file puts in /mnt/UDISK/ directory

#tplayerdemo /mnt/UDISK/test1.mp4 /mnt/UDISK/test2.mp4

chenlinfei

1、#define FASTBOOT_TRANSFER_BUFFER_SIZE (256 << 20)值是错误的。导致"drivers/sunxi_usb/usb_fastboot.c"的while (data_sectors >= nblock) {的代码没有执行到。
2、改成#define FASTBOOT_TRANSFER_BUFFER_SIZE (256 << 1)，while循环能执行进去。
3、但是后面还是无法烧写进去
4、怀疑是ubi相关的问题

chenlinfei

@yaoxiaoyao 昨天搞到半夜，猜测可能是ubi相关的问题。今天再给他一早上的机会，再调试不出来就打算放弃了。

chenlinfei

@yaoxiaoyao
1、这里返回错误应该还能继续执行下去。
2、后面还有个错误，就是#define FASTBOOT_TRANSFER_BUFFER_SIZE (256 << 20)值是错误的。导致"drivers/sunxi_usb/usb_fastboot.c"的while (data_sectors >= nblock) {的代码没有执行到。
3、改成#define FASTBOOT_TRANSFER_BUFFER_SIZE (256 << 1)，while循环能执行进去。
4、但是后面还是无法烧写进去

chenlinfei

@yaoxiaoyao 还没有，真的不行的话只能调试跟进去看了

chenlinfei

.\fastboot.exe flash rootfs ..\rootfs.img
< waiting for any device >
Sending 'rootfs' (16000 KB) OKAY [ 0.539s]
Writing 'rootfs' OKAY [ 4.307s]
Finished. Total time: 16.752s

显示烧写成功，但是实际内容没有更新

chenlinfei

自问自答：
fastboot boot:raw boot boot.fex即可

chenlinfei

执行fastboot的很多命令是成功的，例如 fastboot devices；fastboot reboot
烧写rootfs也可以的
擦写boot分区也可以的

就是烧写boot分区失败：

*** .\fastboot.exe flash boot ..\2021_12_21-Image
fastboot: error: Couldn't parse partition size '0xnot supported'.***

chenlinfei

@whycan

在初始化的时候开启codec，后面不关，可以避免，估计功耗会高点，另外就是断电这个“啵”还是会有

diff --git a/sound/soc/sunxi/sun20iw1-codec.c b/sound/soc/sunxi/sun20iw1-codec.c
index 1dcccdafd..3591e5d17 100644
--- a/sound/soc/sunxi/sun20iw1-codec.c
+++ b/sound/soc/sunxi/sun20iw1-codec.c
@@ -679,8 +679,8 @@ static int sunxi_codec_headphone_event(struct snd_soc_dapm_widget *w,
(0x1 << HP_DRVEN), (0x1 << HP_DRVEN));
break;
case SND_SOC_DAPM_PRE_PMD:

          snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                          (0x1 << HP_DRVEN), (0x0 << HP_DRVEN));

+// snd_soc_component_update_bits(component, SUNXI_HP2_REG,
+// (0x1 << HP_DRVEN), (0x0 << HP_DRVEN));
/* A version of the chip cannot be disable HPLDO and RMC_EN */
if (sunxi_get_soc_ver() & 0x7) {
snd_soc_component_update_bits(component, SUNXI_POWER_REG,
@@ -693,10 +693,10 @@ static int sunxi_codec_headphone_event(struct snd_soc_dapm_widget *w,
snd_soc_component_update_bits(component, SUNXI_RAMP_REG,
(0x1 << RMC_EN), (0x1 << RMC_EN));
}

          snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                          (0x1 << HP_DRVOUTEN), (0x0 << HP_DRVOUTEN));

          snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                          (0x1 << RAMP_OUT_EN), (0x0 << RAMP_OUT_EN));

+// snd_soc_component_update_bits(component, SUNXI_HP2_REG,
+// (0x1 << HP_DRVOUTEN), (0x0 << HP_DRVOUTEN));
+// snd_soc_component_update_bits(component, SUNXI_HP2_REG,
+// (0x1 << RAMP_OUT_EN), (0x0 << RAMP_OUT_EN));
#ifdef SUNXI_CODEC_DAP_ENABLE
if (hw_cfg->dacdrc_cfg & DAP_HP_EN)
dacdrc_enable(component, 0);
@@ -1261,6 +1261,15 @@ static void sunxi_codec_init(struct snd_soc_component *component)
if (sunxi_codec->hw_config.dachpf_cfg)
dachpf_config(component);
#endif
+

  snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                  (0x1 << HP_DRVEN), (0x1 << HP_DRVEN));

  snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                  (0x1 << HP_DRVOUTEN), (0x1 << HP_DRVOUTEN));

  snd_soc_component_update_bits(component, SUNXI_HP2_REG,

                  (0x1 << RAMP_OUT_EN), (0x1 << RAMP_OUT_EN));

}

static int sunxi_codec_startup(struct snd_pcm_substream *substream,

chenlinfei

@whycan 在播放音频会有很响的 “啵” 的一声中说：

正常语音播放的时候，就一直播放一个静默音，这样内部功放就不会动作，就不会啵啵啵。。。

这个操作有点骚。

chenlinfei

使用命令 aplay test.wav播放一个音频文件，当文件播完后会发出很响的“啵”的一声。
跟踪发现是调用snd_pcm_close("hw:audiocodec")时发出的。

不知有什么好的解决方案？

chenlinfei

问题描述

在u-boot代码中设置SPI BCC寄存器，发现BIT[29]设置进去后会丢失。

源代码

printf("1 ????????????????????????????????????????????????? %x\n", get_reg(SPI_BCC));
printf("2 ????????????????????????????????????????????????? %x\n", get_reg(SPI_BCC));
printf("3 ????????????????????????????????????????????????? %x\n", get_reg(SPI_BCC));
                        set_reg(SPI_BCC, get_reg(SPI_BCC) | (1 << 29));

printf("4 ????????????????????????????????????????????????? %x\n", get_reg(SPI_BCC));
printf("5 ????????????????????????????????????????????????? %x\n", get_reg(SPI_BCC));

                        rx_dma_flag = 1;
                        set_reg(SPI_FCR, (get_reg(SPI_FCR) | SPI_RXDMAREQ_EN));

                        spic0_dma_start(0, (unsigned long) rxbuf, rcnt);
                }
        }

"drivers/mtd/awnand/spinand/physic/spic_op.c" 693L, 16039C written                                                              595,4-25      85%

LOG打印

1 ????????????????????????????????????????????????? 1
2 ????????????????????????????????????????????????? 0
3 ????????????????????????????????????????????????? 0
4 ????????????????????????????????????????????????? 20000000
5 ????????????????????????????????????????????????? 0

chenlinfei

@xiaowenge @Banquo
修改点1：见sun6i-dma.c，修改中有暴力魔改。
修改点2：抢占策略改成 Preemption Model (No Forced Preemption (Server))
sun6i-dma.c

uboot中改成4线我不太会改，见下图。请教下你们是怎么改的？
我是这么改的：

chenlinfei

@bedrock 仍需继续努力提升

chenlinfei

@chenlinfei 经过内核驱动等的优化，目前已经到了8.4MB/s，系统启动速率有了显著提升。

chenlinfei

u-boot的读速率也只有不到10MiB/s，怀疑是SPI没有开启4线模式。
尝试开启4线模式后，读写会失败，是否可以帮忙看下？

[02.134]bmp_name=bootlogo.bmp size 38454
38454 bytes read in 4 ms (9.2 MiB/s)

chenlinfei

发现一个可能可以优化的点：每次dma transfer都会触发3次tasklet的执行，其中2次sun6i_dma_tasklet，1次vchan_complete。

[  112.851477] vchan_complete
[  112.854540] sun6i_dma_tasklet
[  112.857142] sun6i_dma_tasklet

chenlinfei

@xiaowenge 其他版本内核是快的吗？

chenlinfei

@xiaowenge 这个问题是否有进展，可否对外share？

chenlinfei

@xiaowenge 另外跟踪下来发现，sun6i_dma_tasklet 的性能比较低，如果能把这个部分优化，还可以提升不少。

总体来看，cpu占用率已经达到100%，性能瓶颈在软件处理上面了。

chenlinfei

@xiaowenge 到不了理论值的，应该小于理论值很多，但是不到理论值的1/10就有点低了。另外，uboot读nand能有接近10MB/s。

是否能优化spi小数据读写？

chenlinfei

@chenlinfei 在 SPI-NANDFLASH性能低问题中说：

2、把SPI频率设置成100MHz，传输速率也有2.x MB/s

笔误，应该是设置成10MHz

chenlinfei

问题描述

使用过程中，发现nandflash的性能比较低，影响了系统启动速率。

初步分析

1、查看驱动代码，发现SPI频率已经配置成了100MHz，也开启了4线模式，按理理论最大传输速率可以达到50MB/s，而实际只有4.5MB/s，软件开销非常大。

2、把SPI频率设置成100MHz，传输速率也有2.x MB/s，再次印证软件开销非常大，软件（CPU）成为瓶颈。

3、通过top和perf工具分析，发现是dma中断处理消耗了大量的资源

4、发现spi通信过程中有大量的1、2、4、64字节的小数据量传输，
如果这些小数据量传输用spi查询模式做，是否能提升性能？

各种测试

dd工具测试：

# dd.coreutils if=/dev/mtdblock3 of=/dev/null bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 22.8465 s, 4.6 MB/s

# dd.coreutils if=/dev/mtdblock3 of=/dev/zero bs=4KB count=10000
10000+0 records in
10000+0 records out
40000000 bytes (40 MB, 38 MiB) copied, 8.60103 s, 4.7 MB/s

# dd.coreutils if=/dev/mtdblock3 of=/dev/zero bs=1KB count=10000
10000+0 records in
10000+0 records out
10000000 bytes (10 MB, 9.5 MiB) copied, 2.21347 s, 4.5 MB/s

top工具分析

CPU:   0% usr  71% sys   0% nic   0% idle   7% io   0% irq  20% sirq
Load average: 1.70 1.30 0.58 1/110 454
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  147     2 root     DW<      0   0%  73% [kworker/0:2H+kb]
    9     2 root     RW       0   0%  11% [ksoftirqd/0]
  449   327 root     D     101m  21%   4% dd.coreutils if=/dev/mtdblock3 of=/dev
   49     2 root     SW       0   0%   2% [spi0]
  205     1 root     S     485m  99%   1% /usr/bin/voice-service
  450   327 root     R     2544   1%   1% top
  300   114 root     S    12040   2%   0% /lib/systemd/systemd-udevd
   96     1 root     S    17764   4%   0% /lib/systemd/systemd-journald
  192     1 messageb S     3292   1%   0% /usr/bin/dbus-daemon --system --addres
   10     2 root     IW       0   0%   0% [rcu_preempt]
  159     2 root     SW       0   0%   0% [xradio_bh]
  202     1 root     S     384m  79%   0% /usr/bin/appx
  215     1 root     S     289m  59%   0% /usr/bin/adbd
  198     1 root     S    87288  17%   0% /usr/bin/gstd --enable-http-protocol -
  167     1 systemd- S    79268  16%   0% /lib/systemd/systemd-timesyncd
  163     1 systemd- S    14340   3%   0% /lib/systemd/systemd-networkd
  114     1 root     S    12040   2%   0% /lib/systemd/systemd-udevd
  299   114 root     S    12040   2%   0% /lib/systemd/systemd-udevd
  321   320 root     S     8484   2%   0% (sd-pam)
q^C07     1 root     S     8344   2%   0% /usr/sbin/wpa_supplicant -u -i wlan0 -

perf工具分析

Samples: 54K of event 'cycles', Event count (approx.): 4804340650               
Overhead  Command       Shared Object      Symbol                               
  25.93%  dd.coreutils  [kernel.kallsyms]  [k] sun6i_dma_tasklet
  13.66%  dd.coreutils  [kernel.kallsyms]  [k] _etext
  10.97%  dd.coreutils  [kernel.kallsyms]  [k] sunxi_spi_dma_cb_rx
   8.69%  dd.coreutils  [kernel.kallsyms]  [k] finish_task_switch
   4.73%  dd.coreutils  [kernel.kallsyms]  [k] preempt_count_sub
   4.56%  dd.coreutils  [kernel.kallsyms]  [k] __asm_copy_to_user
   3.02%  dd.coreutils  [kernel.kallsyms]  [k] get_page_from_freelist
   2.75%  dd.coreutils  [kernel.kallsyms]  [k] __handle_mm_fault
   2.02%  dd.coreutils  [kernel.kallsyms]  [k] preempt_schedule_irq
   1.73%  dd.coreutils  [kernel.kallsyms]  [k] do_page_fault
   1.53%  dd.coreutils  [kernel.kallsyms]  [k] memset
   1.19%  dd.coreutils  [kernel.kallsyms]  [k] dma_pool_free
   1.18%  dd.coreutils  [kernel.kallsyms]  [k] generic_file_read_iter
   1.09%  dd.coreutils  [kernel.kallsyms]  [k] vchan_complete
   1.03%  dd.coreutils  [kernel.kallsyms]  [k] kfree
   0.95%  dd.coreutils  [kernel.kallsyms]  [k] copy_page_to_iter
   0.74%  dd.coreutils  [kernel.kallsyms]  [k] __alloc_pages_nodemask
   0.73%  dd.coreutils  [kernel.kallsyms]  [k] __sched_text_start
   0.63%  dd.coreutils  [kernel.kallsyms]  [k] vmacache_find
   0.61%  dd.coreutils  [kernel.kallsyms]  [k] __add_to_page_cache_locked
   0.57%  dd.coreutils  [kernel.kallsyms]  [k] find_get_entry

chenlinfei 发布的帖子

问题描述

源代码

LOG打印

问题描述

初步分析

各种测试

dd工具测试：

top工具分析

perf工具分析