WhyCan Forum(哇酷开发者社区)

glitching attack 真的太逆天了，竟然还能这么玩

可以的，我在电脑上就是这么用的。我日常开两台电脑，Arch Linux 是主机写代码，Windows 是从机干杂活，用 synergy 共享键鼠。从机 line out 接主机的 line in，这样从机的声音就能在主机放出来了，主要是为了 QQ 和微信听个提示音。

上电找不到 FEL 设备，第一查USB数据线是否畅通，第二查供电是否正常，第三查晶振是否起振。诶?你晶振咋用的是26M?

是不是板子里没放证书？Qt里可以尝试下忽略SSL错误

50Pin 的 RGB LCD 吗？如果是的话有先检查一下控制扫描方向的两个引脚

这是内存初始化失败了，检查焊接和供电

搞个 haveged，可加快 random 初始化

尝试一下在 dts 里加大引脚输出能力

&spi0_pins {
	drive-strength = <40>;
};

CONFIG_SYS_TEXT_BASE 就在 .config 里配置的，全志的会有默认值。其他没有默认值的芯片一般对应的 defconfig 里也会指定上，如果没有默认值或要自定义的，那就自己在 make menuconfig 里配置上就是了。

这几个文件，一般情况下：
1. u-boot 文件是首先编译链接出来的 elf 格式的文件
2. 在1的基础上进行 objcopy 变成纯二进制代码文件，产生 u-boot-nodtb.bin
3. 在2的基础上在屁股那加上 dtb，就变成了 u-boot-dtb.bin，这个文件就是可以跑起来的 u-boot 程序了。u-boot.bin 跟 u-boot-dtb.bin 是一样的
4. 在3的基础上加上一个u-boot 的头，就变成了 u-boot-dtb.img，头里包含了校验码，入口地址(就是CONFIG_SYS_TEXT_BASE)等，这个文件是给 SPL 加载用的，正如我上面所说的，u-boot 要放到指定的内存地址上才能跑，SPL 加载了 U-BOOT 的镜像后，就是从这个头里知道要放哪里的
5. 在4的基础上，在头部那加上带了全志启动头的spl(在 spl 目录下，又是一堆生成文件)，就变成了u-boot-sunxi-with-spl.bin，这是直接给全志的芯片加载用的。

启动的时候，BROM 识别到启动头，加载 SPL 执行，SPL 再去加载带了 u-boot 头的 u-boot，放到头里指示的位置上，再跳转到 u-boot 执行。就这么跑起来了。

以上是一般情况下的流程，不一般的比如带不带 dtb，带不带 spl，是用 legacy image 还是 fitImage，会有些差异。

从哪里开始以及多少空间空闲的，每个型号的芯片都会不一样的，如果 sunxi-tools 尚未支持，要自己去探测和逆向。

根据XFEL的文档，对于 T113，他自带了 DDR 初始化支持，所以可以使用 xfel 先初始化 ddr，然后再写 u-boot 到 ddr 里执行

T113 我没试过不清除具体的情况，但可以分享一下其他的芯片的经验。全志在 FEL 模式下的时候 SRAM 里面是有布局的，一般中间会夹杂着两个 Stack，分别是 IRQ Stack 和普通 Stack，每个芯片具体的位置会不一样。所以如果直接写程序到 SRAM 里，一般情况下是会破坏了栈，从而造成死机。
sunxi-tools 里用了奇技淫巧，分段写入程序，绕开这 stack 位置，然后写入一段特殊的 thunk 程序，再执行这个 thunk 程序，他会备份 stack，然后把之前分段的程序复制回去，然后再跳转执行，以此来来利用整个 SRAM 空间，完事了还能把 Stack 恢复回去，让 FEL 继续正常工作，使接下来能写 u-boot 到 DDR。sunxi-fel spl 干的就是这个事。
参考1: 实现原理
参考2: 代码1 代码2

买全志的开发板前可以先看看这张表https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix，主线 Linux 支持程度高的玩起来轻松一点。当然如果要挑战自己，研究驱动移植的话，就挑支持少的。

把 2048 改成 1024 就行了。V3s 里 YUV 和 RGB 的 scanline 都是 1024，所以可以直接把 https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/sun4i/sun8i_vi_layer.c#L192 这行改成 scanline = 2048 就行了。
然而我的情况比较特殊，我要在别的产品里二次开发，不能换内核，所以就写了个内核模块，启动时 insmod 来动态更改这个配置，这样只能对 YUV 生效，不过反正我也不用 RGB，分享下这个内核模块的代码

#include <linux/init.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include "../linux/drivers/gpu/drm/sun4i/sun8i_mixer.h"

static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
    .vi_num = 2,
    .ui_num = 1,
    .scaler_mask = 0x3,
    .scanline_yuv = 1024,
    .ccsc = 0,
    .mod_rate = 150000000,
};

static struct sun8i_mixer* mixer;
static const struct sun8i_mixer_cfg* old_mixer_cfg;

static int find_device_match(struct device* dev, void* data) {
   return 1;
}

static int __init fixdrm_init(void) {
    struct device_driver* drv;
    struct device* dev;

    drv = driver_find("sun8i-mixer", &platform_bus_type);
    if (!drv) {
        pr_err("driver not found");
        return -ENODEV;
    }

    dev = driver_find_device(drv, NULL, NULL, find_device_match);
    if (!dev) {
        pr_err("device not found");
        return -ENODEV;
    }

    mixer = dev_get_drvdata(dev);
    if (!mixer) {
        pr_err("mixer not found");
        return -ENODEV;
    }

    old_mixer_cfg = mixer->cfg;
    pr_info("scanline_yuv: %d\n", old_mixer_cfg->scanline_yuv);

    mixer->cfg = &sun8i_v3s_mixer_cfg;
    
    return 0;
}

static __exit void fixdrm_exit(void) {
    if (mixer && old_mixer_cfg) {
        mixer->cfg = old_mixer_cfg;
    }
    pr_info("exit\n");
}
 
module_init(fixdrm_init);
module_exit(fixdrm_exit);

MODULE_LICENSE("GPL");

我今天在研究 V3s 的 DRM，内核版本就是 5.2，发现一个问题，输入图像格式是 NV21，然后调用 drmModeSetPlane 时如果 SRC_W 超过 1024 图像就显示就不正常，1024以下完全没问题。请问我碰到的这个问题跟您解决的BUG是否相关？

/dev/disp 是全志的显示模块驱动的设备文件，主线中功能与之对应的是 drm，故主线中不会有 /dev/disp，除非将全志的显示驱动移植过来。尚不清除用全志的解码驱动与主线的 drm 能不能合作。
主线也有对应的解码驱动，叫 cedrus( https://linux-sunxi.org/Sunxi-Cedrus )，他能很好的与 drm 合作。只是 v3s 的还没合并到主线，这是开发中的代码 https://github.com/mcerveny/linux/commits/v3s_videocodec_v4 ，我没试过，但有计划去尝试。主线的解码接口叫 v4l2-request，可以参考这个工程如何调用解码以及如何调用 drm 进行渲染
https://github.com/bootlin/v4l2-request-test ，关于主线的渲染的流程可参考这个文档FOSDEM_Presentation_2018___Lukas_Rusak.pdf

全志的显示模块 DE 分多个通道，其中通道0和通道1为视频通道，可接受 YUV 和 RGB 格式，通道之间可以透明叠加。一个通道分多个层(一般4层)，层之间可叠加。同一个通道只接受一种像素格式，默认情况下 /dev/fb0 配置在通道1的第0层上，那么放视频就要放在通道0上了。在放视频的时候可看一下当前的 DE 状态 /sys/class/disp/disp/attr/sys
比如我这个

# cat /sys/class/disp/disp/attr/sys 
screen 0:
de_rate 297000000 hz, ref_fps:58
mgr0: 1024x600 fmt[rgb] cs[0x0] range[limit] unblank direct_show[false] 
	lcd output	backlight( 50)	fps:58.5	1024x 600
	err:0	skip:1	irq:154729	vsync:0	vsync_skip:0	
   BUF    enable ch[0] lyr[0] z[1] prem[N] a[globl 255] fmt[ 77] fb[1280, 736;1280, 736;1280, 736] crop[   0,   0,1280, 720] frame[  85,   0, 853, 480] addr[5b400000,5b4e6000,       0] flags[0x       0] trd[0,0]
   BUF    enable ch[1] lyr[0] z[0] prem[N] a[pixel 255] fmt[  0] fb[1024, 600;1024, 600;1024, 600] crop[   0, 600,1024, 600] frame[   0,   0,1024, 600] addr[58100000,       0,       0] flags[0x       0] trd[0,0]

ch0 lry0 是 fmt77 格式，也就是NV21格式，就是我显示视频的层了。ch1 lyr0 是 fmt0 格式，是 ARGB 格式，就是/dev/fb0，是我显示UI的层。如果当前只有一个 fmt0 的层，那么铁定不是"硬渲染"的。

我不知道有没有现成的软件，我这个播放器是自己写的，但是是公司的项目，不好开源出来。

最简单的方法，看 CPU 占用，如果硬解的话，基本不占 CPU。另外还可以用 lsof 看进程是否打开了硬解相关的设备文件，比如全志驱动的 /dev/cedar_dev 和 /dev/ion，主线驱动的 /dev/video0 和 /dev/media0。
还有一点，如果放视频的话，除了硬解，还要"硬渲染"配合，因为全志硬解输出的是 NV21 格式，如果用 framebuffer 放的话，要从 YUV 转 RGB，即使使用 NEON 也慢的要命。全志驱动的 /dev/disp 或者主线驱动的 /dev/dri/card0 就是干这个的。

@baidxi
只是做了微小的工作，让 sunxi-fel 可以识别 A133，能下载程序，执行 thunk 代码。计划是下一步开始研究 SPL

这要看你USB设备端的需求：
1. 如果设备端仅仅是与主机通过虚拟串口来数据通信的，那么就不需要设置波特率。
2. 如果设备端要做一个类似于USB转串口的应用，需要让主机端来设置设备串口输出的波特率的，那么就要设置波特率。

简单的讲，对于 ACM 设备，主机会把波特率、数据位这些串口参数封装成一个数据包请求下发到设备端，如果你没调API设置过，那么是有一个默认值的。设备端收到这些参数后用来干啥是设备端的业务问题。ACM通信本身是没有波特率这些需求的。

可以将多个SPI设备与文件系统FLASH挂载在一起的，因为系统运行过程中执行程序或者读取文件也是按扇区读 flash 内容到内存中再执行或操作的，这完全是操作系统层面的逻辑，不会在硬件上独占SPI总线，因此可以与其他SPI设备挂载在一起。
有两点要注意：
  1. 其他设备的 CS 脚需硬件上拉，原因是 CPU 上电后 BROM 读取 U-BOOT SPL 的时候，他不知道有其他 SPI 设备的存在，所以不会去控制这些 SPI 设备的片选信号，如果不硬件上拉，这些 SPI 设备的 CS 脚的状态是不确定的，会干扰总线，造成启动失败。
  2. 使用多个 SPI 设备，需要改用 GPIO 来控制 CS 信号

我在 dts 中这么配置了就能用了

/ {
	soc {
		ehci0: usb@01c1a000 {
			compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
			reg = <0x01c1a000 0x100>;
			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
			resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
			status = "okay";
		};

		ohci0: usb@01c1a400 {
			compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
			reg = <0x01c1a400 0x100>;
			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
			<&ccu CLK_USB_OHCI0>;
			resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
			status = "okay";
		};
	};
}

&usb_otg {
	dr_mode = "host";
	status = "okay";
};

&usbphy {
	status = "okay";
};

这是触发了 Data Abort 中断，访问了无效地址就会触发这个中断