查看6410数据手册可以看到，内存开始地址应该是0x50000000，而实际在real6410开发板使用过程中U-boot加载Linux内核都是加载到0xC0008000处开始运行，我猜测（还没有看代码来验证猜测）这个是因为Linux启动内核的地址为0xC0008000，而U-boot为了和Linux保持一致，故对内存也做了映射，方便用户使用。下面先以内核2.6.28为例来先来看一下Linux中这

一、U-Boot入门二、嵌入式linux内核制作三、根文件系统制作

一、linux设备驱动程序概述1、驱动模型2、驱动分类3、驱动程序学习方法1、驱动模型1驱动模型2模型1：没有实现驱动程序的复用，对每一个使用此串口的应用程序都要重新编写驱动程序。这样造成了很大浪费。模型2：很好的解决了模型1中，驱动程序没有复用的问题，实现了驱动的复用，可是驱动的编写没有统一的规范。2、设备驱动的分类：字符设备、块设备、网络接口、其他分

图为应用程序与驱动程序的关系图：当应用程序调用系统函数read时，会首先经过内核的处理，然后再去调用驱动程序中相应的函数。可以使用反汇编查看read系统函数的实现：arm-linux-gcc -static -g read_mem.c -o read_mem然后：arm-linux-objdump -D -S read_mem >dumpvi dumpread(fd

ARM内核驱动-内存-链表-进程管理

思维导图设计led.c#include #include #include #include #include #include "led.h"#define LEDCON 0x7f008800#define LEDDAT 0x7f008808unsigned int *led_config; unsigned int *led_data; struct cde

linux系统中，硬件访问实质就是对寄存器的访问，或者说是对外部ram的访问。1、硬件访问的实质驱动程序控制设备，主要是通过访问设备内的寄存器来达到控制目的，因此我们讨论如何访问硬件，就成了如何访问这些寄存器了。2、地址映射在linux系统中，无论是内核程序还是应用程序，都只有使用虚拟地址，而芯片手册中给出的硬件寄存器地址或者RAM地址则是物理地址，无法直接使用，因

---nfs:server is not responding,still trying    原因与解决方案---本来还以为是nfs出了故障，但是google了一下发现原来不是nfs的原因，而是由于传送的数据太大，出现数据包丢失现象。   NFS 的默认传输协议是 UDP，而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。可用的解决方案是：在客户端改用TCP协议，使用下面的

先简单介绍一下NFS服务器是什么？ 　　NFS server可以看作是一个FILE SERVER,它可以让你的PC通过网络将远端得NFS SERVER共享出来的档案MOUNT到自己的系统中，在CLIENT看来使用NFS的远端文件就象是在使用本地文件一样。 　　RPC（Remote Procedure Call） 　　NFS本身是没有提供信息传输的协议和功能的，但NFS却能让

u-boot的环境参数中有两个和内核启动相关的，它们是bootcmd和bootargs1.u-boot中和环境参数有关的命令       printenv：打印当前环境参数       setenv param_name "value"：设置环境参数       saveenv：保存环境参数到FLASH2.bootcmd：这个参数包含了一些命令，这些

linux内核简介，linux内核的基本知识。内核的编译和安装。

一、字符驱动编程模型在linux系统中，设备的类型非常繁多，比如：字符设备，块设备，网络接口设备，USB设备，PCI设备，平台设备，混杂设备...，而设备类型不同，也意味着其对应的驱动程序模型不同，这样就导致了我们需要去掌握众多的驱动程序模型。那么能不能从这些众多的驱动模型中提炼一些具有共性的规则，则是我们能不能学好linux驱动的关键。1、设备描述结构cdev在任何一