uboot dm9000驱动故障

手头有一块6410开发板,已经有别人提供的uboot代码(基于2011.06),但是在检测dm9000时显示下面的输出:


Net:   No ethernet found.

当然其他网络命令例如ping等都执行失败。

但是在(include/configs/*6410*.h)下添加一行(增加debug)信息:


#define DEBUG

那么就能够检测到dm9000:


Net:   dm9000

配置ip地址后执行ping命令结果如下:


hwgw # setenv ipaddr 192.168.211.212
hwgw # ping 192.168.211.2
Trying dm9000
dm9000 i/o: 0x18000300, id: 0x90000a46
DM9000: running in 16 bit mode
MAC: 00:12:39:8f:ad:b3
operating at 100M full duplex mode
Using dm9000 device
sending ARP for 02d3a8c0
ARP broadcast 1
packet received
packet received
Receive from protocol 0x806
Got ARP
Got ARP REPLY, set server/gtwy eth addr (00:e0:4c:26:51:75)
Got it
packet received
packet received
Receive from protocol 0x800
Got IP
len=28, v=45
host 192.168.211.2 is alive

当前开发板没有jtag口,只能通过打印的方式来进行调试,大概试了有一天多时间,

在dm9000_initialize等函数中加入类似printf("hello\n");之类的代码时,会出现错误.

另外,如果添加#define CONFIG_DM9000_DEBUG配置,也会出现相同的错误。

具体错误信息就是在显示下面的信息后就重启uboot:


DRAM: 128M

而该信息恰好是board_init_f中接近于最后几行的代码,board_init_f中最后一行是调用relocate_code函数,

所以我怀疑这种情况下有可能relocate_code失败引起的。而2011.06版本乃至以后版本的uboot都采用类似的代码,
都是在board_init_f最后执行relocate_code,然后再执行board_init_r。而这个relocate_code是用汇编代码编写,

出错后很难找出故障原因,可能还不如老版本(老版本中relocate_code在board_init_f之前就执行完毕了)的更容易移植。

这个bug暂时也没法调试成功,但不影响正常使用 ,留到以后对uboot有了更深入了解后再来看这个问题。

uboot dm9000驱动故障,布布扣,bubuko.com

时间: 2024-11-04 20:25:40

uboot dm9000驱动故障的相关文章

一,Linux-3.19内核移植DM9000驱动(JZ2440)

文档时间:2018-08-25 交叉编译器:arm-linux-gcc-4.3.2 Ubuntu版本:16.04 kernel版本:linux-3.19 1,移植内核自带的 DM9000 网卡驱动 使用之前制作的 uboot,kernel 和 文件系统,在 uboot 终端把 machid 设置为 0x16a (SMDK2440),启动内核,然后输入 ifconfig 命令,发现不支持 DM9000,如下图所示: 而如果把 machid 设置为 0x7cf (MINI2440),执行同样的操作,

【linux驱动分析】之dm9000驱动分析(三):sk_buff结构分析

[linux驱动分析]之dm9000驱动分析(一):dm9000原理及硬件分析 [linux驱动分析]之dm9000驱动分析(二):定义在板文件里的资源和设备以及几个宏 [linux驱动分析]之dm9000驱动分析(四):net_device结构体 [linux驱动分析]之dm9000驱动分析(五):另外几个重要的结构体 [linux驱动分析]之dm9000驱动分析(六):dm9000_init和dm9000_probe的实现 [linux驱动分析]之dm9000驱动分析(七):dm9000的卸

ok6410 uboot 网卡驱动

ok6410使用的网卡是DM9000,从启动信息来看uboot默认的网卡是CS8900. 修改驱动代码(board/Samsung/ok6410/ok6410.c): int board_eth_init(bd_t *bis) { int rc = 0; #ifdef CONFIG_CS8900 rc = cs8900_initialize(0,CONFIG_CS8900_BASE); #endif #ifdef CONFIG_DM9000 rc =dm9000_initialize(bis);

DM9000驱动移植在mini2440(linux2.6.29)和FS4412(linux3.14.78)上的实现(deep dive)篇一

关于dm9000的驱动移植分为两篇,第一篇在mini2440上实现,基于linux2.6.29,也成功在在6410上移植了一遍,和2440非常类似,第二篇在fs4412(Cortex A9)上实现,基于linux3.14.78,用设备树匹配,移植过程中调试和整体理解很重要,一路上幸有良师益友指点,下面详细介绍: 1.物理时序分析相关 DM9000芯片是DAVICOM公司生产的一款以太网处理芯片,提供一个通用的处理器接口.一个10/100M自适应的PHY芯片和4K双字的SRAM.内部框架如下,涉及

dell usb3.0驱动故障

一.故障现象 dell3046 dell3050新主机安装操作系统时,在BIOS.pe中能够正常使用USB键鼠,安装成功后,进入windows登录后,安全模式,USB键鼠无任何反应. 二.处理过程 1.因使用wds安装系统,首先错误的认为是wds本身的问题,尝试在WDS中检查各个环节,均未见异常 2.尝试在主机上安装纯净版系统,安装完成后,USB设备依旧无法使用 3.将主机自带驱动程序备份,使用dism将驱动封入wim镜像文件,安装系统后故障依旧 4.在主机上安装纯净版系统,U盘在安装界面无法发

u-boot器件驱动模型(Device&Drivers)之uclass (转)

一.剧情回顾 在上一篇链接器的秘密里面我们讲到我们用一些特殊的宏让链接器帮我们把一些初始化好的结构体列好队并安排在程序的某一个段里面,这里我例举出了三个和我们主题相关段的分布情况,它们大概如下图所示:(我们可以通过搜索宏ll_entry_declare来找到它们) 那么问题来了,那它们三个是什么关系呢?它们在程序里面是怎么被用到的呢? 二.剧透 剧透环节希望你们喜欢,uclass对驱动进行了归类处理,它描述了具有相似方法的驱动,而不管它们的具体形式.比如对于GPIO它们会具有读取管脚和设置管脚输

uboot 版本号生成过程

uboot版本号貌似与实际开发不相关,但是我现在遇到一个bug与版本号关联密切. 这个bug与<uboot dm9000驱动故障>基本上是一样的,但是在上一篇博文中我没有详细说明. bug发生现象: 将svn仓库代码通过git-svn下载到本地,然后编译,生成的u-boot-nand.bin通过sd卡烧写到开发板,然后重启开发板, 但是仅仅会重复显示如下信息: U-Boot 2011.06-00000-gccc7fce-svn222 (May 28 2014 - 09:55:33)Hwgw64

基于335X平台的UBOOT中交换芯片驱动移植

基于335X平台的UBOOT中交换芯片驱动移植 一.软硬件平台资料 1.开发板:创龙AM3359核心板,网口采用RMII形式. 2.UBOOT版本:U-Boot-2016.05,采用FDT和DM. 3.交换芯片MARVELL的88E6321. 4.参考文章:本博客基于335X的UBOOT网口驱动分析. 二.移植主要步骤 1.准备工作: (1).必须熟悉U-Boot-2016.05中的网口驱动构架,熟悉其中各个网口设备结构体的意义,网口初始化流程.重点详细分析常规基于phydev的驱动初始化的过程

[uboot] (番外篇)uboot 驱动模型(转)重要

[uboot] uboot流程系列:[project X] tiny210(s5pv210)上电启动流程(BL0-BL2)[project X] tiny210(s5pv210)从存储设备加载代码到DDR[uboot] (第一章)uboot流程——概述[uboot] (第二章)uboot流程——uboot-spl编译流程[uboot] (第三章)uboot流程——uboot-spl代码流程[uboot] (第四章)uboot流程——uboot编译流程[uboot] (第五章)uboot流程——u