dwmac-sun8i 1c30000.ethernet eth0: Link is Down
dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
请我一直不停的打印这个是怎么回事?
有可能是网线不好或者硬件问题
这个确实比较难,因为每个系统的硬件都不一样,写一份通用的 kernel config 教程不太现实
我当时折腾这个的时候,就是一点点慢慢试,一次砍掉一点内核功能,慢慢降低大小,没法启动了就 undo 取消掉的东西,最后搞出来了一个 672KB 的极简kernel,能在 qemu-system-x86_64 里运行。过程我写在这里了:https://github.com/Unturned3/Microdot/blob/master/wiki/3_miniSystem/3_miniKernel.md
如果你的目标是在树莓派等平台上运行的话,那估计还得在这个基础上添加一堆硬件模块的支持。
如果保留的话,别人通过调试口就能把应用程序读出来了。
1,内核里关闭调试串口功能,关闭adb功能。
2,保留调试口,设置登陆账户及密码。
3,其他没想到,群友有说禁用外部读写功能(还没去搜如何实现)。
你得评估一下,想破解你产品的是什么样的人。普通挖坑网用户,纯粹出于好奇?竞争公司?还是FBI、NSA?
大多数情况下,只要你的实体产品能落到对方手中,那基本就避免不了被破解了。这年头,各种攻击手法层出不穷,前段时间有个油管小哥用 voltage glitching 轻松破解 Apple Air Tag 的固件…… 苹果钱和资源这么多的都防不住,我们就洗洗睡了吧
I really do not understand what is going on with the Chinese postal service.
In case you've been living under a rock: deliveries in general are kinda fucked recently due to c0v1d resurgences here.
By the way,
@ SITE ADMINISTRATORS: I DEMAND MY ACCOUNT TO BE DELETED ! I ALREADY REPORTED THIS WEB SITE TO THE POLICE.
这链接里哪里写了关于硬件编码的东西?
https://whycan.com/t_8713.html
应该和你这个是同样的问题
bigbat 说:楼主的硬解和硬编的资料从哪里来的
在代码里扣出来的。
确实,基本全靠摸索
这个仓库 有一些关于 API 的资料
https://linux-sunxi.org/Video_Engine 有关于 VE 寄存器的资料
折腾了很久,终于实现了这个功能!!!
自从 aodzip 大佬分享了他的 cedar 仓库后,我就一直想试试 V3s 的 h264 硬编码,可惜 OpenMax 这个中间层就是个渣渣,不仅莫名其妙的占用大量内存,在 ffmpeg 中也无法调整各种编码参数。V3s 上实测,编码 dvp 摄像头采集的 640x480 的视频就已经是极限了…… 显然这和 datasheet 中提及的 1080p @ 30fps 还差的有点远
于是我直接放弃 openmax、ffmpeg,参考了网上 V4L2 和全志 Cedar API 的例程,开始手写程序。全志 video_encoder_API_guide.pdf 里的描述可以说是“惜字如金”,而且网上各个例程使用这些函数的方法也有差异,比如有些每帧调用一次 AllocInputBuffer, 有些没有使用 ReturnOneAllocInputBuffer 等等,导致这些函数的具体作用比较难理解
这些例程大都是读取某个 yuv 文件,将每帧的数据 memcpy 到 CedarVE 申请的缓冲区内,然后再编码。对于 640x480 之类的低分辨率还没太大问题,但是编码 1920x1080 的时候帧率就直接掉到10以下并且CPU使用率占满,因为程序花费了大量的时间来拷贝数据,非常低效。
要实现零拷贝的话,一般是采取 V4L2_MEMORY_DMABUF(Linux DMA-BUF 机制)或者 V4L2_MEMORY_USERPTR(V4L2 直接将数据写入 userspace 的某个 buffer)这两种方法。可惜,libcedarc 的 API 不支持前者,而 Linux 的 sun6i-video 驱动又恰巧不支持后者。现在剩下的只有 V4L2_MEMORY_MMAP。不过如果我们希望将自己申请的 buffer 交给 libcedarc 使用的话,我们需要知道 buffer 的物理地址;可是 V4L2 API 中并没有能让我们获取 MMAP buffer 物理地址的功能……
由于本人能力不足,实在看不懂 cedar 驱动的架构,于是只好另辟蹊径,放弃为 cedar 添加 dma-buf 支持的想法。在深入研究 V4L2 MMAP 机制后,发现其实 MMAP 过程中返回 buffer 中一个 private struct 里的 dma_addr 就是 MMAP 缓冲区的 dma 地址。
不过 dma_addr 怎么转换成物理地址呢?无数次实验后,发现 kernel 自带的 virt_to_phys 函数貌似可以完成这个功能…… 这个函数返回的 phys_addr,经过 busybox devmem 读写数据验证,的确是相应 V4L2 MMAP buffer 的物理地址…… 这肯定不是 virt_to_phys 的正确用法,不过能用就先用着吧…… (路过的大神请手下留情哈哈)
知道如何获取 phys_addr 后,剩下的就是解决如何将这个信息传回给 userspace 的应用。仔细阅读 sun6i-video 中 V4L2 相关代码后,发现有一个叫做 vidioc_default 的无用 ioctl,简直完美!写了个简单的 ioctl handler 便解决了这个问题。现在 userspace 的应用只需将 V4L2 MMAP 返回的 buffer 传递给这个 ioctl,就能获取该 buffer 的物理地址。
最后一个问题:cedar 在 Linux 5.5 及以上的版本就无法编译了,因为 dma-buf 中某个结构体无法对齐。恼人的是,5.10 后又添加了许多对于全志 SoC 的驱动改进,实在是想用。于是我又花了很多时间仔细阅读 Linux 5.4、5.5 附近的 commit 记录,发现 Linux 在 5.5 以后移除了 Android ION 这个内存管理器的相关代码,并且顺带移除了 dma-buf 一个结构体中的元素。而老旧的 cedar 恰好又需要这个 ION 机制…… 我只好写了个 patch 将这个删掉的元素重新添加进 dma-buf 的结构体(顺带修改了一些头文件、syscall参数错误,等等),于是 cedar 在最新主线 Linux 5.19 上就能运行了,舒服!
代码:https://github.com/Unturned3/h264enc_demo
配套的 buildroot “包”:https://github.com/Unturned3/v3s3
顺便介绍一下:v3s3 是一个 buildroot external tree (“外部树”),并不是一个独立的开发环境,需要和一个 buildroot 包配合使用。它的优点是当前项目所有的文件和 buildroot 内部文件是分开的,非常干净,便于管理;日后更换、升级 buildroot 版本简直不要太爽。v3s3 仓库除了硬编码 demo 外,还有许多其他好东西,例如一个极优化的 Linux 内核 config,0.3 秒从 Starting kernel 到 /sbin/init,硬件AES256加速驱动,等等。具体详见 repo README。(如果对你有帮助的话,不妨给个star,逃
# 切换到某个合适的目录
cd /some/working/directory
# 下载 buildroot external tree
git clone https://github.com/Unturned3/v3s3
# 下载并解压任意一个 buildroot 版本(最近的版本应该都能用;我测试的是2022.05.1)
wget buildroot.org/downloads/buildroot-x.y.z.tar.gz
tar -xf buildroot-x.y.z.tar.gz
# 切换至 buildroot 目录,并初始化配置
cd buildroot-x.y.z
make BR2_EXTERNAL=../v3s3 licheepi_zero_defconfig
# 打开 buildroot 配置目录
make nconfig
# 勾选 h.264 硬编码 demo 选项
External options --->
[*] CedarVE H.264 encoding demo
# 下载所需的软件包
make source
# 编译
make all
# 烧录 SD 卡 (将 /dev/sdX 替换成合适的路径)
sudo dd if=output/images/sdcard.img of=/dev/sdX bs=4M
本人用的硬件是荔枝派Zero,OV5640 DVP (parallel) 摄像头。荔枝派Zero 第一次上电可能会出现 OV5640 i2c ID 错误的情况,目前暂不知原因,不过重启(软重启,i.e. reboot, 不是插拔电源)一次便可解决。只要 /dev/video0, /dev/media0 存在就没太大问题。media-ctl -p 这个指令也可以用于查看 OV5640 是否注册成功。
用串口、或者 ssh 登录后,/root 目录下会有一个 h264enc_demo 的二进制文件:
./h264enc_demo [width] [height] [FPS] [n_frames]
支持 640x480, 1280x720, 1920x1080。n_frames 为采集的帧数,如果不写的话默认450帧。
所有分辨率均支持 30 FPS;640x480 模式下额外支持 60FPS (这是 OV5640 驱动的限制)
h264enc_demo 会将编码流输出至 /mnt/out.h264,如果录制的 n_frames 较大,可考虑在 /mnt 上挂载一个大 SD 卡分区来存储数据。
copy_video.sh 可通过 scp 指令将 /mnt/out.h264 拷贝至某台远程电脑(需要你自己设置合适的 scp destination)
在装有 ffmpeg 的电脑上,可通过 ffmpeg -framerate 30 -i out.h264 -c copy out.mp4 指令将裸 h264 流转换为 MP4
哦哦,你用的是 Linux 5.2,那 haveged 可能是比较好的选择了
Linux 5.6 以及更高版本都自带 haveged 和相关的算法。我目前用的是 5.19,开机5秒多也就 crng init done 了
参考:
https://wiki.archlinux.org/title/Haveged
https://github.com/jirka-h/haveged/issues/57#issuecomment-803705461
https://github.com/jirka-h/haveged/commit/297bdf1fc52fc6f59d0495f911d4e594b4d29190
你用的是哪个 defconfig?
这应该是 boot time entropy starvation 造成的 https://stackoverflow.com/a/20960019/18061591
我前段时间遇到过,就是开机后熵不足,导致内核无法生成随机数(各种加密算法需要),所以就没法启动 sshd
可以考虑不等待 sshd 服务启动(例如在启动指令的末尾加一个 & 使其在后台中运行),或者试试把内核的 RANDOM_TRUST_BOOTLOADER 打开
各大 Linux 发行版的官方仓库,或者知名开源软件,基本都是一套规矩,而且多多少少也遵守 Linux Standard Base 协议
如果你要自己安装官方库之外的软件,那也一般都装在 /usr/local、/opt 之类的地方,也不会跟官方库和配置文件冲突
就算你是自己编译代码,大多数情况也可以把生成的 binary 打包成当前发行版的格式,然后用发行版自带的包管理器来安装,这样也方便日后查看、升级
要是随便从哪个网站仓库搞个安装包或者源码来编译,直接暴力 sudo make install 安装到 /usr/bin, /usr/lib,不造成冲突才怪呢
我以前刚开始玩 Arch Linux 的时候这一点深有体会…… Linux 系统变得很乱,绝大部分情况是因为用户自己没管理好
You need to customize your shell's PS1 environment variable; see https://linuxhint.com/bash-ps1-customization/
https://github.com/buildroot/buildroot/tree/master/board/licheepi
Mainline buildroot has support for the licheepi
@jungle
楼主在 readme (https://github.com/aodzip/libcedarc) 里头写了一个 “Based on lindenis-v536 SDK”,我猜他发布的 libcedarc 可能是在 lindenis 的 libcedarc 上面添加、修改了代码,所以多出了某些功能?
有匹配的,我用过
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.d2f12e8da8LGO4&id=566547808242&_u=7j91ik3adab
这个
只能说我当时买的时候是直接可以用的,不保证店家是否修改过
ok,谢谢谢谢
Lindenis 的 V833 开发板 ( https://github.com/lindenis-org , http://wiki.lindeni.org/index.php/Lindenis_V833 )有配套的 V833 SDK。好像 V831 和 V833 内部是同一个芯片,只不过V831自带DDR?既然如此的话,V833 的 SDK 能否用在 V831 上呢?
QFN88封装的Cortex-A7,还带一个小NPU,这芯片有点好玩
https://origin-www.cypress.com/products/ez-usb-cx3-programmable-mipi-csi-2-usb-30-camera-controller
这个 cyusb306a 貌似不错,好像 sdk 也公开
可以试试看
这个视频 有没出处呀,原网址能不能贴一下?
原网址是twitter……
荔枝派5.2确实不支持isp
主线的话,可以看一下这个patch,不过我自己还没试过
https://www.spinics.net/lists/arm-kernel/msg919937.html
为什么我编译V3s固件,使用initramfs,
文件系统使用的是buildroot-2017.08.1/output/target这个目录,
可是如论如何都引导不了系统
是连内核都完全启动不了,还是内核能启动但无法进入userspace?
如果你进入 output/target 这个目录,你会发现有一个叫 THIS_IS_NOT_YOUR_ROOT_FILESYSTEM 的文件,是 buildroot 提醒你不要使用 output/target 来直接烧录rootfs。具体原因你可以阅读 THIS_IS_NOT_YOUR_ROOT_FILESYSTEM 的内容,不过大概意思就是 buildroot 不是以root 用户身份运行的,所以无法正确的设置某些文件权限。
(回复完才发现这是个2017年发的问题…… 很奇怪为什么这个帖子浮到首页来了)
V3s/V3x/S3/S3L 强烈推荐这个:
(V3s/V3x/S3/S3L/R11通吃)小智V3x开发板smallwitpi lite u-boot/linux/buildroot测试
https://whycan.com/t_7248.html#p69178
请问大佬这个和主线 buildroot 里头自带的 V3s build 有什么区别吗?
这东东如何加密呢
在全志芯片F1C100S/V3S/V831上实现裸机加密方案,防盗版进行时(不采用专用加密芯片)。
https://whycan.com/t_6507.html
unturned3 说:你 buildroot make menuconfig 打开了 c++ support 和相关选项后,有没有重新执行 make clean && make all ?
没,我再试试,谢谢
https://buildroot.org/downloads/manual/manual.html#full-rebuild
建议看一下 buildroot 文档,尤其是 “8.2. Understanding when a full rebuild is necessary” 这一块。buildroot 缺点就是每次menuconfig 做点啥改动,几乎都得重新 make clean all
I found ISP support recently added for v3s, but I cannot understand where to find patch and how to apply it.
Does anybody interested in ISP module for v3s?(Image Signal Processing)
Oh wow, thanks for the info. I think Paul Kocialkowski is a maintainer at Bootlin, who did a ton of work mainlining Allwinner stuff.
This patch adds the device tree nodes for the ISP. If you check out the previous patch (https://www.spinics.net/lists/arm-kernel/msg919937.html), you can see the code added to drivers/staging/media/sunxi/sun6i-isp
I don't think a kernel has been released with these staging patches yet, so you have to apply these patches yourself if you'd like to test these new functions out. The patches are included in each of these commit messages.
晕哥 说:找到 /etc/inittab 文件的
console::respawn:/sbin/getty -L console 0 vt100 # GENERIC_SERIAL
修改为:
console::respawn:-/bin/sh
重启后就没有恼人的 login 提示了.
确实可以了,请问这是什么原理?
/etc/inittab 就是 /sbin/init 的配置文件。console::respawn 设置的就是Linux控制台怎么初始化。用 /sbin/getty 就是把控制台交给getty,然后getty会提示你输入用户名、密码之类的东西来login。把控制台交给 /bin/sh,就没有了login 的那些步骤了,直接进入 shell
突然翻到这个老帖,其实不用看哪个好了,因为全志出来了个V831: https://widora.cn/topic/698
偷偷说一句:价格比210便宜。单核A7内置64M还有0.2T算力。
大佬,链接失效了,能再发一个吗?是不是widora有v831的板子啊
我在淘宝上看到了这个 https://item.taobao.com/item.htm?spm=a230r.1.14.63.55b4407aCA8QxY&id=637071844357&ns=1&abbucket=4#detail
不过不知道这个算不算开发板,感觉功能引出挺少的
哪天买一个研究研究,跑自己搞的模型试试
@unturned3
No, I get such fps using hard codec using ffmpeg -c:v h264_omx , without cedarx I get ~ 25fps 640x480, I dont understand why so high cpu load when using cedarxI also cannot encode 1280x720 and more due to ion memory allocation failure (I set CMA to 32MB as aodzip recommended)
How did you invoke ffmpeg? May I see the exact command? Because I'm not quite sure how to do it properly.
I just went through the trouble of changing my kernel from 5.10 to 5.4.35, and I'm about to downgrade buildroot from 2020.11 to 2020.08. Building ffmpeg with --enable-omx in buildroot 2020.11 gives me a missing header OMX_core.h error.
@unturned3
Hello, how many fps and maximum resolution do you get with cedarx from aodzip? I can encode 640x480 at ~50fps data from ov5640 using ffmpeg - CPU load 100%
Hey,
I haven't actually tried cedarx yet; planning to do so in the next few days. Did you obtain the 50fps h264 encoding result using CPU only (no cedarx)? That sounds pretty impressive.
和最新的5.10 dma结构体不对应会报错
drivers/staging/media/sunxi/cedar/ion/ion.c:1026:2: error: unknown field ‘map’ specified in initializer .map = ion_dma_buf_kmap, ^ drivers/staging/media/sunxi/cedar/ion/ion.c:1026:9: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .map = ion_dma_buf_kmap, ^ drivers/staging/media/sunxi/cedar/ion/ion.c:1026:9: note: (near initialization for ‘dma_buf_ops.mmap’) drivers/staging/media/sunxi/cedar/ion/ion.c:1027:2: error: unknown field ‘unmap’ specified in initializer .unmap = ion_dma_buf_kunmap, ^ drivers/staging/media/sunxi/cedar/ion/ion.c:1027:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .unmap = ion_dma_buf_kunmap,
好像5.6之后,map、unmap就被删了
https://github.com/torvalds/linux/commit/4337ebbbbda3fb82e4fd928188a86e0bff0e9042
这怎么办...
这个问题我也遇到过,最后换了根网线就解决了(不过我用的是5.3.5内核)
荔枝派 V3s 以太网 Link is Up,Link is Down 奇怪行为
https://whycan.com/t_6461.html
@scy251147
你说的 module_init,module_exit 啥的,是 Linux 内核模块的东西。控制个LED,为啥要用这么复杂的机制?
在 userspace 里随便写个 C 程序或者 shell 脚本方便得多啊
目前找到了这篇文章,看的稀里糊涂,主要是荔枝派nano上烧写的linux,里面也没gcc呀
难道说需要我在ubuntu上编译好,然后往荔枝派nano的设备树上挂载?
你可以直接把你的代码放入 buildroot 的系统中去,让它自动帮你交叉编译,或者自己搞个 arm-linux-gnueabi 的交叉编译器手动编译,然后把二进制文件拷贝到荔枝派上去。
https://www.rock-chips.com/a/en/products/RV11_Series/2017/0118/828.html
我看Rockchip 官网上说RV1108 带了一个 CEVA XM4 DSP,但我 baidu,google 搜遍了都没找到任何相关信息或者资料。有哪位大佬知道这咋回事?这个DSP是保护的很严的商业机密吗?怎么感觉网上能找到的Rockchip 资料比全志的还少
我看了看 CEVA XM4 DSP 的资料,感觉挺香,想在这上面试试计算机视觉算法玩一玩。
看了 https://whycan.com/t_2719.html 后决定搞搞 V3s 的硬件 crypto 加速器,看看能不能降低 curl 用 https 时候 CPU 的占用率。
先 make nconfig,把 buildroot 里的 cryptodev 这个包给勾选上
然后再 make linux-nconfig,把 Enable loadable module support 打开,再把 Cryptographic API 目录中的这些全部勾选上:
-*- Cryptographic algorithm manager
<*> Userspace cryptographic algorithm configuration
-*- Null algorithms
<*> CBC support
<*> ECB support
<*> User-space interface for hash algorithms
<*> User-space interface for symmetric key cipher algorithms
<*> User-space interface for random number generator algorithms
<*> User-space interface for AEAD cipher algorithms
[*] Hardware crypto devices --->
<*> Support for Allwinner Security System cryptographic accelerator
[*] Support for Allwinner Security System PRNG
然后运行 make linux-rebuild,make all,完成后把 sdcard.img 烧写到 tf 卡上
开机登陆 root 账户后运行 modprobe cryptodev,然后用这个指令检查能否看见 /dev/crypto:
# openssl engine -c -tt
(devcrypto) /dev/crypto engine
[DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-ECB, AES-192-ECB, AES-256-ECB, MD5, SHA1]
[ available ]
(dynamic) Dynamic engine loading support
[ unavailable ]
以下是测试的结果,用的指令是 openssl speed -evp <cipher_name> -elapsed
很奇怪,用了 cryptodev 硬件加速后,居然比不用还要慢。。。不知道为什么
### cryptodev unloaded ###
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 18810.66k 23347.43k 25082.11k 25546.07k 25684.65k 25695.57k
aes-192-cbc 16683.07k 20266.92k 21494.95k 21869.57k 21973.67k 21981.87k
aes-256-cbc 15192.08k 17997.65k 19016.11k 19281.24k 19360.43k 19365.89k
md5 6845.81k 21962.92k 54481.83k 88408.75k 107834.03k 109532.50k
sha1 5587.66k 16467.97k 37492.65k 55125.33k 63941.29k 64678.57k
### cryptodev loaded ###
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 3116.29k 8921.07k 16968.36k 21918.72k 23582.04k 23751.34k
aes-192-cbc 2927.55k 8132.22k 15011.53k 18872.66k 19830.10k 19895.64k
aes-256-cbc 2778.49k 7607.04k 13453.14k 16726.02k 17446.23k 17563.65k
md5 764.50k 2949.72k 10953.05k 33556.48k 82395.14k 92034.39k
sha1 690.34k 2573.21k 8964.01k 23353.34k 43308.37k 46088.19k
然后我试了试用 curl 通过 https 下载个大文件,发现 cryptodev 用不用,CPU占用率都在95%左右浮动
V3s 的硬件 crypto 加速器还有哪位大佬用过吗?有没有哪位能分享一下经验?
多谢多谢!
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun8i-v3s.dtsi
主线 Linux 貌似已经支持 crypto engine了!
第 271 行:
crypto@1c15000 {
compatible = "allwinner,sun8i-v3s-crypto",
"allwinner,sun8i-a33-crypto";
reg = <0x01c15000 0x1000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
clock-names = "ahb", "mod";
resets = <&ccu RST_BUS_CE>;
reset-names = "ahb";
};
我用的是官方buildroot 2020.11.3,主线Linux 5.3.5,以太网设备树是从 荔枝派 zero-5.2.y 这里抄过来的。
这是开机时 kernel 打印的信息,看起来以太网驱动貌似没啥问题:
[ 0.670942] libphy: Fixed MDIO Bus: probed
[ 0.675134] CAN device driver interface
[ 0.679641] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 0.685514] dwmac-sun8i 1c30000.ethernet: No regulator found
[ 0.691600] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 38000 (expect 58000)
[ 0.701003] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[ 0.708253] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[ 0.715489] dwmac-sun8i 1c30000.ethernet: COE Type 2
[ 0.720454] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[ 0.727250] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[ 0.732909] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[ 0.738591] dwmac-sun8i 1c30000.ethernet: device MAC address 52:57:dc:70:bf:b8
[ 0.746056] libphy: stmmac: probed
[ 0.750101] dwmac-sun8i 1c30000.ethernet: Found internal PHY node
[ 0.756447] libphy: mdio_mux: probed
[ 0.760062] dwmac-sun8i 1c30000.ethernet: Switch mux to internal PHY
[ 0.766461] dwmac-sun8i 1c30000.ethernet: Powering internal PHY
[ 0.773048] libphy: mdio_mux: probed
登录后运行 ifconfig,然后尝试用 udhcpc 来获取 IP,会卡在 “sending discover” 上:
# ifconfig eth0 up
[ 780.217368] dwmac-sun8i 1c30000.ethernet eth0: PHY [0.1:01] driver [Generic PHY]
[ 780.226392] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found
[ 780.233807] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[ 780.241472] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[ 780.248026] dwmac-sun8i 1c30000.ethernet eth0: configuring for phy/mii link mode
# udhcpc
udhcpc: started, v1.32.0
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
过一会儿后(几十秒到几十分钟不等),kernel 会打印一个 “Link is Up” 的信息,然后这时候运行 udhcpc 立即就能获取到 IP:
[ 878.003861] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
# udhcpc
udhcpc: started, v1.32.0
udhcpc: sending discover
udhcpc: sending select for 192.168.3.190
udhcpc: lease of 192.168.3.190 obtained, lease time 86400
deleting routers
adding dns 192.168.3.1
有些时候这个以太网还会在 Down、Up 之间来回变动:
# udhcpc
udhcpc: started, v1.32.0
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
[ 101.283907] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[ 102.323796] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[ 110.483599] random: crng init done
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
[ 126.243915] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[ 127.283790] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[ 132.483944] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
udhcpc: sending discover
udhcpc: sending select for 192.168.3.190
udhcpc: lease of 192.168.3.190 obtained, lease time 86400
deleting routers
adding dns 192.168.3.1
#
请问有哪位大佬遇到过这个情况吗?荔枝派Zero的以太网是不是还需要什么设备树以外的特别的配置?奇怪的是,如果我在荔枝派上用 USB-Ethernet 转接器,同样的问题就从来没有出现过,udhcpc 也总是立即就可以获取 IP。
多谢指教!
貌似这也是同样的问题
ov2640在荔枝派上使用ffmpeg录制视频报以下错误,在虚拟机上运行则不会。
http://whycan.com/t_6367.html
(出处:哇酷开发者社区)
麻烦哪位大佬指点指点……
我用的是aodzip大佬的buildroot包,试着运行ffmpeg 来采集640x480的图像,转成 mjpeg 传到localhost 上,但是v4l2 报错内存不足:
ffmpeg \
-s 640:480 \
-framerate 10 \
-pixel_format uyvy422 \
-f video4linux2 -i "/dev/video0" \
-filter:v fps=10,scale=320:240 \
-f mjpeg udp://127.0.0.1:8080
...
[video4linux2,v4l2 @ 0x5a420] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device
[video4linux2,v4l2 @ 0x5a420] Time per frame unknown
[video4linux2,v4l2 @ 0x5a420] ioctl(VIDIOC_STREAMON): Cannot allocate memory
/dev/video0: Cannot allocate memory
这是为啥呢?如果把 -s 640:480 换成 -s 320:240 就不会报错,而且通过网络传输还能稳定10fps。
ffmpeg 运行 320x240 的时候,我用free -m 查看内存占用,发现还剩40MB 没用。采集640x480的图像不会就把剩下的40MB全占了吧?这是不是驱动有什么问题?
麻烦哪位大佬指点指点... 我自己搞了一星期了都没搞明白