uboot

最开始并没有注意到这个问题, 因为从设备拿到手, 用USB Burning Tool刷入潜龙版的安卓4.4.2, 再到运行EmuELEC, Armbian, 再到给Kernel 5.3的Armbian编译RTL8189FTV的驱动, 都还算顺利. 因为Kernel 5.3也差不多搞定了, 开始打安卓的主意, 想看看能不能跑7.x版本的安卓. 固件包下了几个, 要开始刷的时候出了状况, 发现按着reset键再也无法进入USB Burning Mode了. 几经调查, 试了另外两台一样已经刷过的R3300L, 百度上查类似的案例, 发现其他人也存在这种情况. 而且网友们提供的处理方法(4R19接地)完全无效. 于是开始研究UBOOT 这个设备跑过的系统不外乎潜龙的安卓4.4.2, 以及各种版本的EmuELEC, 各种版本的Armbian, 通过查资料, 发现Linux下面的fw_printenv和fw_setenv命令可以查看及修改UBOOT下的配置. EmuELEC下可以直接运行, 但是在高版本的Armbian下, 仅有可执行文件, 缺/etc/fw_env.config, 于是又查资料找到了对应S905L的config. 通过分析UBOOT的配置, 可以确认EmuELEC和Armbian都会对UBOOT配置进行修改, 但是它们的修改只是在bootcmd里加东西,

1、前言 2、board_init_f函数 来源： https://www.cnblogs.com/Cqlismy/p/12006287.html

1、前言 在前面的文章 https://www.cnblogs.com/Cqlismy/p/12000889.html 中，已经简单分析了low_level_init函数，其调用流程如下： save_boot_params_ret | cpu_init_crit | 　　| | 　　lowlevel_init | 　　| | 　　s_init | _main 接下来，则继续往下分析_main函数。 2、_main函数 来源： https://www.cnblogs.com/Cqlismy/p/12002764.html

嵌入式开发涉及硬件和软件两部分，个人目前主要是做嵌入式软件部分，使用uboot+linux的整体方案。这里所说的“嵌入式软件环境”，不是指宿主机上的嵌入式开发环境，而是指目标机中的运行软件环境，只是简要介绍一种布局及相应的实现步骤。 一、软件环境的布局 开发板的datasheet中都有详细的地址空间的划分，其中比较重要的两块是：DDR地址空间和Flash地址空间。DDR空间是系统和应用的运行空间，一般由linux系统自身进行使用和管理；Flash空间是系统和应用载体的存放空间，一般需要在使用前进行划分，由应用开发者进行管理。在这里以我现在正在做的项目进行简单的示例和说明。 其中，Flash的整体地址空间为：0x34000000~0x34FFFFFF,共16MB,使用的是Nor Flash芯片。布局需要做的工作是： 确定uboot二进制文件的大小，使用的地址范围 确定linux kernel镜像文件的大小，使用的地址范围 确定rootfs 根文件系统的镜像文件大小，使用的地址范围 估计整体应用方案所需的空间大小，选择可使用的地址范围 完成上述工作后，项目的布局如下： uboot：0x34000000~0x34080000, 512KB kernel : 0x34080000~0x34180000, 1MB, 文件大小为952.8KB rootfs : 0x34180000

嵌入式开发涉及硬件和软件两部分，个人目前主要是做嵌入式软件部分，使用uboot+linux的整体方案。这里所说的“嵌入式软件环境”，不是指宿主机上的嵌入式开发环境，而是指目标机中的运行软件环境，只是简要介绍一种布局及相应的实现步骤。 一、软件环境的布局 开发板的datasheet中都有详细的地址空间的划分，其中比较重要的两块是：DDR地址空间和Flash地址空间。DDR空间是系统和应用的运行空间，一般由linux系统自身进行使用和管理；Flash空间是系统和应用载体的存放空间，一般需要在使用前进行划分，由应用开发者进行管理。在这里以我现在正在做的项目进行简单的示例和说明。 其中，Flash的整体地址空间为：0x34000000~0x34FFFFFF,共16MB,使用的是Nor Flash芯片。布局需要做的工作是： 确定uboot二进制文件的大小，使用的地址范围 确定linux kernel镜像文件的大小，使用的地址范围 确定rootfs 根文件系统的镜像文件大小，使用的地址范围 估计整体应用方案所需的空间大小，选择可使用的地址范围 完成上述工作后，项目的布局如下： uboot：0x34000000~0x34080000, 512KB kernel : 0x34080000~0x34180000, 1MB, 文件大小为952.8KB rootfs : 0x34180000

1、CoM-P6UL是盈鹏飞科技有限公司基于NXP原厂i.mx6ul芯片生产研发的核心板，本文将对CoM-P6UL适配NXP的基于Linux4.1.15版本的uboot板级源码。 2、开发环境 目标板：CoM-P6UL（Nand Flash：256MB，RAM：256MB） 主机：Linux ubuntu 4.15.0-70-generic 交叉编译工具链：gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf 来源： https://www.cnblogs.com/Cqlismy/p/11961485.html

uboot的relocation原理详细分析 转自：http://blog.csdn.net/skyflying2012/article/details/37660265 最近在一直在做uboot的移植工作，uboot中有很多值得学习的东西，之前总结过uboot的启动流程，但uboot一个非常核心的功能没有仔细研究，就是uboot的relocation功能。 这几天研究下uboot的relocation功能，记录在此，跟大家共享。 自己辛苦编辑，转载请注明出处，谢谢！ 所谓的relocation，就是重定位，uboot运行后会将自身代码拷贝到sdram的另一个位置继续运行 ，这个在uboot启动流程分析中说过。 但基于以前的理解，一个完整可运行的bin文件，link时指定的链接地址，load时的加载地址，运行时的运行地址，这3个地址应该是一致的 relocation后运行地址不同于加载地址 特别是链接地址，ARM的寻址会不会出现问题？ 新版uboot跟老版uboot不太一样的地方在于新版uboot不管uboot的load addr（entry pointer）在哪里，启动后会计算出一个靠近sdram顶端的地址，将自身代码拷贝到该地址，继续运行。 个人感觉uboot这样改进用意有二，一是为kernel腾出低端空间，防止kernel解压覆盖uboot，二是对于由静态存储器

1.1：menuconfig 重点会用到两个文件：.config 和 Kconfig，.config 文件前面已经说了，这个文件保存着 uboot 的配置项，使用 menuconfig 配置完 uboot 以后肯定要更新.config 文件。Kconfig文件是图形界面的描述文件，也就是描述界面应该有什么内容，很多目录下都会有 Kconfig 文件 1.2：打开图形界面，设置好要设置的项目后， make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8再编译uboot, 注意不能用用 mx6ull_alientek_emmc.sh ，因为在编译之前会清理工程，会删除掉.config 文件 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_alientek_emmc_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig 1.3：过程分析：当输入 make menuconfig 以后会匹配到顶层 Makefile 的如下代码 %config: scripts_basic outputmakefile FORCE $(Q)$(MAKE) $(build)=scripts/kconfig $@

1.1：bootcmd 保存着 uboot 默认命令，uboot 倒计时结束以后就会执行 bootcmd 中的命令。这些命令一般都是用来启动 Linux 内核的，比如读取 EMMC 或者 NAND Flash 中的 Linux 内核镜像文件和设备树文件到 DRAM 中，然后启动 Linux 内核;板子第一次运行 uboot 的时候都会使用默认值来设置 bootcmd，环境变量。在 include/env_default.h看下默认值 env_t environment __PPCENV__ = { ENV_CRC, /* CRC Sum */ 1, /* Flags: valid */ const uchar default_environment[] = { "bootargs=" CONFIG_BOOTARGS "\0" "bootcmd=" CONFIG_BOOTCOMMAND "\0"　　　　　............ } 1.2：CONFIG_BOOTCOMMAND的定义用如下脚本语言定义：找设备树文件；切换到emmc上；再扫描是否有mmc设备（没有的话从网络启动），运行loadbootscript环境变量若能加载到boot.src，则运行bootscript环境变量；否则运行loadimage环境变量（loadimage=fatload mmc 1:1

1.解压好u-boot后，打开uboot根目录的README文件，在software configuration 里有写明，如果要针对某个单板进行配置，需要执行：make <board_name>_config 其中uboot支持的board_name可以在根目录的include/configs/下查看。 2.makefile 2.1 uboot version确定 （Makefile 24-29行） U_BOOT_VERSION “1.3.4xyz” 1)uboot版本号分为4个级别： VERSION : 主板号 PATCHLEVEL : 次版本号 SUBLEVEL : 再次版本号 EXTRAVERSION : 另外附加的版本信息 这4个用 . 分隔开共同构成了最终的版本号。 2）makefile中版本号最终生成一个变量U_BOOT_VERSION,这个变量记录了Makefile中配置的版本号。 Include/version_autogenerated.h文件是编译过程中自动生成的一个文件，所有源目录中没有，但是编译过后的uboot中就有了。它里面的内容是一个宏定义，宏定义的值就是我们在Makefile中配置的uboot版本号。 3）验证方法：自己修改主makefile中几个version有关的变量，然后编译uboot，然后烧录到SD卡中，从SD卡中启动