From: Rogan Dawes Date: Tue, 17 Aug 2010 13:19:24 +0200 Subject: [U-Boot] Debugging why my kernel won't start In-Reply-To: <4C6A6741.7030002@free.fr> References: <4C68E7C0.1040801@dawes.za.net> <4C699C6E.2010706@dawes.za.net> <4C6A600B.5020809@free.fr> <4C6A62AC.6010206@dawes.za.net> <4C6A6741.7030002@free.fr> Message-ID: <4C6A703C.8080205@dawes.za.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2010/08/17 12:41 PM, Albert ARIBAUD wrote: >> I had a debug statement in the loop, printing out the above at each >> iteration. Since it never completed the loop, copying/moving the entire >> kernel (609564 bytes remaining), I think it is safe to assume that it >> never got to the point of trying to boot the kernel. > > Sorry, I'd missed that one. No problem, there was a lot of data there. > I do think you're overwriting u-boot with the kernel. What location does > your u-boot load at? What location is the manufacturer's u-boot supposed > to be loading at? See their TEXT_BASE in the board config file (or link > file maybe). My U-Boot is configured to load at 0x3000000 (48MB), as far out of the way as possible. That is, using the mkimage tool, which is how I get my rebuilt u-boot onto the machine. This is my command line: $ make clean mrproper dns323_b1_config && make && \ mkimage -A arm -O u-boot -T kernel -C none \ -a 0x3000000 -e 0x3000000 -n "UBoot dns323" \ -d u-boot.bin uImage.bin My TEXT_BASE is identical to yours: 0x100000 Does that make a difference, if the u-boot image is chain loaded from another one? This is what I found in the vendor code: ./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f10000 ./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f40000 ./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f00000 I'm not sure which config has been used for the version of u-boot on my board, though. At any rate, those are all substantially higher than I am currently using. I'll try with a higher value, and see what happens. > FYI, in my u-boot edminiv2 support code, I had issues with big kernels, > so I decided to move u-boot's final location as high in RAM as by board > allows, so that it never will be overwritten by Linux (unless I load a > 63+ MB kernel, that is :) ) That was my reasoning with the 48MB, too :-) Rogan