页次： 1
ubuntu oops既然是直接死机,syslog的信息全他妈的0000000000000?嵌入式linux死机串口还有oops出来!好家伙!
Raw data transmitter (c) 2015 befinitiv GPL2
device wlan0 entered promiscuous mode
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1c40000
[00000000] *pgd=81c8a831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000005 [#1] ARM
Modules linked in: rtl8188eusHI3518(O) cfg80211 rfkill hi_mipi(O) hi3518e_adec()
CPU: 0 PID: 169 Comm: tx Tainted: P O 4.9.37 #11
Hardware name: Hisilicon Hi3518EV20X (Flattened Device Tree)
task: c1ca43a0 task.stack: c27f0000
PC is at 0x0
LR is at rtw_monitor_xmit_entry+0x148/0x204 [rtl8188eusHI3518]
pc : [<00000000>] lr : [<bf3ad278>] psr: 60000013
sp : c27f1d38 ip : c298f060 fp : 00000000
r10: 00000000 r9 : 00000000 r8 : 00000000
r7 : 00008180 r6 : 80809b6e r5 : 0114a89d r4 : 1f004267
r3 : c1c0d900 r2 : 000011c7 r1 : c29d91a0 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 81c40000 DAC: 00000055
Process tx (pid: 169, stack limit = 0xc27f0190)
Stack: (0xc27f1d38 to 0xc27f2000)
1d20: 00000000 00000000
1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fa0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[<bf3ad278>] (rtw_monitor_xmit_entry [rtl8188eusHI3518]) from [<00000000>] ( ()
Code: bad PC value
---[ end trace 9956beced7b189f8 ]---
Kernel panic - not syncing: Fatal exception in interrupt
---[ end Kernel panic - not syncing: Fatal exception in interrupt其实也看不出啥出来,只能确定堆栈的地址指向 rtw_monitor_xmit_entry,这个函数的问题?哪一行呢?
拍打323 说：经过对比代码，EZ设置监听模式时没用fcsfail，但是radioflags有检测crc，而openHD不检测radioflags的crc，都是丢掉crc错误的，反正也不能根据错误包纠正？而是根据fec找回丢的包？我抓包发现原始的wifibroadcast项目有的sum sequence 没有，应该是mac80211层根据radioflags的crc错误标志丢弃了!
我的理解，
Wi-Fi硬件的OFDM物理层也有类似FEC的机制（如802.11g 6Mbps 的 1/2），包内的错误应该是靠这个纠正；
包内错误无法纠正的时候包crc就会错，导致丢包；
当一组包，例如FEC设置为 8数据/4FEC ，即一组12个包中，丢失4个以内时，通过FEC算法可以恢复出8个正确的数据包；
当12个包中丢失超过4个则无法恢复这组共8包的数据，导致H264码流中某个NALU损坏，视频的某个或某些Slice损坏；
视频解码器把这些个Slice显示成花屏，剩下的再继续显示……
（我也不知道这么个流程对不对x拍打323 说：监听模式丢包应该是正常的，2.4g太拥挤了!那他们的图像不花屏应该用了另外的措施？openhd有用rtp？视频编码打包时用了rtp或者解码时判断帧有丢包，丢的用xx填充，否则全花……
我之前用EZ倒是经常遇到花屏，现象为从屏幕某个高度的一行开始，往下全部重复该行的颜色
搜了一下ytb，比如这样：https://youtu.be/teTOSCb_4kE?t=472 （这人用的2.3G）另外在QOpenHD那边README看到一段话，
On the GroundPi, the app is simply an overlay on hello_video just like the original OSD, so video should work exactly the same as it always has, though there is an additional PiP overlay available for the 2nd camera if one is being used.
如果用的也是hello_video那和EZ应该没区别
但我没读过hello_video源码，不知道它的内部怎么处理的坏包，不知道坛子里有没有大佬看过……orz
用wifibroadcast信道gstreamer解密显示完全大片绿.发送端不直接采样摄像头h264,改cat h264文件发送就不会大片绿.
拍打323 说：我用的网卡是ar9271,,我怀疑人家ez-wifibroadcast的树梅派的ath9k驱动做了修改,错误包没有丢弃,让fec来纠正.
dev <devname> set monitor <flag>*
Set monitor flags. Valid flags are:
none: no special flags
fcsfail: show frames with FCS errors
control: show control frames
otherbss: show frames from other BSSes
cook: use cooked mode
active: use active mode (ACK incoming unicast packets)
人家profile里监听模式flags没用 otherbss fcsfail ,用的none.我玩的wifibroadcast用了otherbss fcsfail.这个我觉得可以在树莓派上用wireshark抓包验证一下
拍打323 说：但是为什么遵循DCF,一直占用信道不是更好.
我的理解，发包的时候可以选择发RTS包，驱动里也可以魔改调节随机退避的窗口大小，就相当于可以在DCF规则下作弊
经过对比代码，EZ设置监听模式时没用fcsfail，但是radioflags有检测crc，而openHD不检测radioflags的crc，都是丢掉crc错误的，反正也不能根据错误包纠正？而是根据fec找回丢的包？我抓包发现原始的wifibroadcast项目有的sum sequence 没有，应该是mac80211层根据radioflags的crc错误标志丢弃了!
拍打323 说：libc0607 说：有可能你的网卡（或网卡驱动）丢掉了crc错误的包？
大半年没碰这个了，不少都忘了XD监听模式接收端收到错的不会发送重传?还是说监听模式不按802.11协议来?还是说发送这边哪里设置成广播,单播?
监听模式也可以使用udp协议发送数据?监听模式接收端收到错的不会发送重传
重传应该是MAC的协议层做的事，可能在mac80211里，也可能在fullmac的驱动里，mac80211的做法应该是收到数据包之后加上radiotap头并传给所有的监听接口通过监听接口发包你可以就理解为……FM广播之类的（？），从监听接口送了数据进去就会有对应的数据包在空中传输
虽然发包的时候也会有CCA之类的机制，但重传是（比监听接口更上的）上层协议栈做的事，
空中传输的时候会有不可预知的情况，比如楼下有个微波炉路过，那这期间传送的包很可能就会出现校验错误另，记得W60x系列芯片的文档里提到，调用他们的自由通信接口时收到的包不含FCS错误的包；
Linux下是否上报FCS错误的包取决于设置监听模式时的flag，具体可以看下 iw monitor mode flags 这篇；但如果驱动没按这个实现那也没办法orz另2，像ezwifibroadcast这种项目也绝对不可能使用802.11的ACK机制，因为如果发射端和接收端的物理距离大于无线电波在一个SIFS时间内于该情况下可以传播的距离的话那就会一直卡死在重传……SIFS大概是10us这个级别的，无线电波也就刚飞了几公里而已（（
UDP那个我也不知道怎么一两句话解释明白，这俩概念离得太远了……x 要不再具体问下
但是为什么遵循DCF,一直占用信道不是更好.
拍打323 说：大佬有研究wifibroadcast吗?这种通过监听模式实施通讯的方式,包注入和接收,他有经常丢包的问题吗?我研究了一阵子不用fec和用fec都会丢包.用fec也有0.001-0.01的丢包率.
有可能你的网卡（或网卡驱动）丢掉了crc错误的包？
大半年没碰这个了，不少都忘了XD
我用的网卡是ar9271,,我怀疑人家ez-wifibroadcast的树梅派的ath9k驱动做了修改,错误包没有丢弃,让fec来纠正.
dev <devname> set monitor <flag>*
Set monitor flags. Valid flags are:
none: no special flags
fcsfail: show frames with FCS errors
control: show control frames
otherbss: show frames from other BSSes
cook: use cooked mode
active: use active mode (ACK incoming unicast packets)
人家profile里监听模式flags没用 otherbss fcsfail ,用的none.我玩的wifibroadcast用了otherbss fcsfail.
这是正常的吗?
接收
root@abc-T6Series:/home/abc/wifibroadcast/wifibroadcast-master# ./rx -b 8 -r 8 -f 1400 wlx00127b2405c7 > testdropfream.h264
DLT_IEEE802_11_RADIO Encap
Could not fully reconstruct block 5278! Damage rate: 0.090909 (1 / 11 blocks)
Signal (card 0): -23dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
Signal (card 0): -23dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Could not fully reconstruct block 5586! Damage rate: 0.002522 (2 / 793 blocks)
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -25dBm
Signal (card 0): -24dBm
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -27dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -25dBm
Signal (card 0): -26dBm
Signal (card 0): -26dBm
^Z
[1]+ 已停止 ./rx -b 8 -r 8 -f 1400 wlx00127b2405c7 > testdropfream.h264
root@abc-T6Series:/home/abc/wifibroadcast/wifibroadcast-master#
发送
/nfsroot # ./samplev 2|./tx -b 8 -r 8 -f 1400 wlan0
Raw data transmitter (c) 2015 befinitiv GPL2
device wlan0 entered promiscuous mode
128 data packets sent (interface rate: 256.000)
256 data packets sent (interface rate: 512.000)
384 data packets sent (interface rate: 768.000)
512 data packets sent (interface rate: 512.000)
640 data packets sent (interface rate: 640.000)
768 data packets sent (interface rate: 768.000)
896 data packets sent (interface rate: 597.333)
1024 data packets sent (interface rate: 682.667)
1152 data packets sent (interface rate: 768.000)
1280 data packets sent (interface rate: 640.000)
1408 data packets sent (interface rate: 704.000)
1536 data packets sent (interface rate: 768.000)
1664 data packets sent (interface rate: 665.600)
1792 data packets sent (interface rate: 716.800)
1920 data packets sent (interface rate: 768.000)
2048 data packets sent (interface rate: 682.667)
2176 data packets sent (interface rate: 725.333)
2304 data packets sent (interface rate: 768.000)
2432 data packets sent (interface rate: 694.857)
2560 data packets sent (interface rate: 731.429)
2688 data packets sent (interface rate: 768.000)
2816 data packets sent (interface rate: 704.000)
2944 data packets sent (interface rate: 736.000)
3072 data packets sent (interface rate: 768.000)
3200 data packets sent (interface rate: 711.111)
3328 data packets sent (interface rate: 739.556)
3456 data packets sent (interface rate: 768.000)
3584 data packets sent (interface rate: 716.800)
3712 data packets sent (interface rate: 742.400)
3840 data packets sent (interface rate: 768.000)
3968 data packets sent (interface rate: 721.455)
4096 data packets sent (interface rate: 744.727)
4224 data packets sent (interface rate: 768.000)
4352 data packets sent (interface rate: 725.333)
4480 data packets sent (interface rate: 746.667)
4608 data packets sent (interface rate: 768.000)
4736 data packets sent (interface rate: 728.615)
4864 data packets sent (interface rate: 748.308)
4992 data packets sent (interface rate: 768.000)
5120 data packets sent (interface rate: 731.429)
5248 data packets sent (interface rate: 749.714)
5376 data packets sent (interface rate: 768.000)
5504 data packets sent (interface rate: 733.867)
5632 data packets sent (interface rate: 750.933)
5760 data packets sent (interface rate: 768.000)
5888 data packets sent (interface rate: 785.067)
6016 data packets sent (interface rate: 752.000)
6144 data packets sent (interface rate: 768.000)
6272 data packets sent (interface rate: 737.882)
6400 data packets sent (interface rate: 752.941)
6528 data packets sent (interface rate: 768.000)
6656 data packets sent (interface rate: 783.059)
6784 data packets sent (interface rate: 753.778)
6912 data packets sent (interface rate: 768.000)
7040 data packets sent (interface rate: 782.222)
7168 data packets sent (interface rate: 754.526)
7296 data packets sent (interface rate: 768.000)
7424 data packets sent (interface rate: 781.474)
7552 data packets sent (interface rate: 755.200)
7680 data packets sent (interface rate: 768.000)
7808 data packets sent (interface rate: 743.619)
7936 data packets sent (interface rate: 755.810)
8064 data packets sent (interface rate: 768.000)
8192 data packets sent (interface rate: 780.190)
8320 data packets sent (interface rate: 756.364)
8448 data packets sent (interface rate: 768.000)
8576 data packets sent (interface rate: 779.636)
8704 data packets sent (interface rate: 756.870)
8832 data packets sent (interface rate: 768.000)
8960 data packets sent (interface rate: 779.130)
9088 data packets sent (interface rate: 757.333)
9216 data packets sent (interface rate: 768.000)
9344 data packets sent (interface rate: 778.667)
9472 data packets sent (interface rate: 757.760)
9600 data packets sent (interface rate: 768.000)
9728 data packets sent (interface rate: 778.240)
9856 data packets sent (interface rate: 758.154)
9984 data packets sent (interface rate: 768.000)
10112 data packets sent (interface rate: 777.846)
10240 data packets sent (interface rate: 758.519)
10368 data packets sent (interface rate: 768.000)
10496 data packets sent (interface rate: 749.714)
10624 data packets sent (interface rate: 758.857)
10752 data packets sent (interface rate: 741.517)
10880 data packets sent (interface rate: 750.345)
11008 data packets sent (interface rate: 759.172)
11136 data packets sent (interface rate: 768.000)
11264 data packets sent (interface rate: 750.933)
11392 data packets sent (interface rate: 759.467)
11520 data packets sent (interface rate: 768.000)
11648 data packets sent (interface rate: 776.533)
11776 data packets sent (interface rate: 759.742)
11904 data packets sent (interface rate: 768.000)
12032 data packets sent (interface rate: 776.258)
12160 data packets sent (interface rate: 760.000)
12288 data packets sent (interface rate: 744.727)
12416 data packets sent (interface rate: 752.485)
12544 data packets sent (interface rate: 760.242)
12672 data packets sent (interface rate: 768.000)
12800 data packets sent (interface rate: 775.758)
12928 data packets sent (interface rate: 760.471)
13056 data packets sent (interface rate: 768.000)
13184 data packets sent (interface rate: 775.529)
13312 data packets sent (interface rate: 760.686)
13440 data packets sent (interface rate: 768.000)
13568 data packets sent (interface rate: 753.778)
13696 data packets sent (interface rate: 760.889)
13824 data packets sent (interface rate: 747.243)
13952 data packets sent (interface rate: 754.162)
14080 data packets sent (interface rate: 761.081)
14208 data packets sent (interface rate: 768.000)
14336 data packets sent (interface rate: 774.919)
14464 data packets sent (interface rate: 761.263)
14592 data packets sent (interface rate: 768.000)
14720 data packets sent (interface rate: 774.737)
14848 data packets sent (interface rate: 761.436)
14976 data packets sent (interface rate: 768.000)
15104 data packets sent (interface rate: 755.200)
15232 data packets sent (interface rate: 761.600)
15360 data packets sent (interface rate: 749.268)
15488 data packets sent (interface rate: 755.512)
15616 data packets sent (interface rate: 761.756)
15744 data packets sent (interface rate: 768.000)
15872 data packets sent (interface rate: 755.810)
16000 data packets sent (interface rate: 761.905)
16128 data packets sent (interface rate: 768.000)
16256 data packets sent (interface rate: 774.095)
16384 data packets sent (interface rate: 762.047)
16512 data packets sent (interface rate: 768.000)
16640 data packets sent (interface rate: 756.364)
16768 data packets sent (interface rate: 762.182)
16896 data packets sent (interface rate: 750.933)
17024 data packets sent (interface rate: 756.622)
17152 data packets sent (interface rate: 762.311)
17280 data packets sent (interface rate: 768.000)
17408 data packets sent (interface rate: 756.870)
17536 data packets sent (interface rate: 762.435)
17664 data packets sent (interface rate: 768.000)
17792 data packets sent (interface rate: 773.565)
17920 data packets sent (interface rate: 762.553)
18048 data packets sent (interface rate: 768.000)
18176 data packets sent (interface rate: 757.333)
18304 data packets sent (interface rate: 762.667)
18432 data packets sent (interface rate: 768.000)
18560 data packets sent (interface rate: 757.551)
18688 data packets sent (interface rate: 762.776)
18816 data packets sent (interface rate: 768.000)
18944 data packets sent (interface rate: 773.224)
19072 data packets sent (interface rate: 762.880)
19200 data packets sent (interface rate: 768.000)DDR最终测试结果 610MHz正常 615MHz测试失败
https://whycan.com/files/members/2487/12.png
为何测试失败,是阻抗匹配没做好,还是pcb本身的阻抗有偏差?设计的时候可以加调试电阻电容焊接位解决吗?板子厂公布了pcb阻抗测试结果吗?他们自己从来不搞这些的吧,客户自己花钱打样用仪器自己确认的吧,板厂有双面板的阻抗测试?
达克罗德 说：buildroot 偏向于给你提供定制rootfs的选项，怎么选由用户来定。而且buildroot是选好了之后对源码进行交叉编译；而openwrt我的理解类似于Debian，官方给你选好了很多软件包和服务，组成了一个有特色的操作系统。当然由于带了包管理，你还是可以事后安装你想要的软件包。不像buildroot是自己编源码，在openwrt这些软件包事先都是已经编译好的，放到了源服务器上。
我感觉使用上差不多，主要都是三步：
1、git clone 下载源码
2、make xxx_defconfig（OpenWrt不需要此步）、make menuconfig 选择芯片型号、开发板型号、需要的功能和软件
3、make 编译生成linux镜像文件，，执行这一步的时候都会先根据选择的芯片编译生成交叉编译器，，然后再用交叉编译器编译系统镜像感觉真的很相似，，
要说差异的话，似乎OpenWrt的官方源码https://github.com/openwrt/openwrt中支持的芯片型号几乎都是路由器芯片，，非路由器芯片很少
不过这似乎也不是啥大问题，，因为我们下载源码的时候一般都是去芯片/开发板供应商那里去下载，，而不是去openwrt或buildroot的github去下载
什么源码去芯片供应商下?比如v3s移植openwrt ,''make menuconfig 选择芯片型号、开发板型号、需要的功能和软件''openwrt源码自带的吗?
页次： 1