On Fri, Jan 11, 2013 at 03:38:21PM -0800, Steve deRosier wrote: > Hi all, > > I'm stuck trying to get Linux to boot from U-Boot on a Coldfire system and > I'd love some ideas of what to try next. > > I'm upgrading a uClinux system from a 2.4 kernel to 3.3. Additionally I'm > trying to upgrade the boot-loader from u-boot 1.1.6 to release 2012.07. > The board is based on a MCF5235EVB. I did the Linux upgrade first, and > am successfully getting the existing system boot loader to boot my upgraded > Linux 3.3 images. Now I've moved on to upgrading u-boot. > > I was able to get U-Boot to come up successfully and it recognizes my Linux > image and a bootm command starts just fine. It does the checks, > uncompresses, and goes to boot. I turned on the debug messages in U-Boot, > so I get the "## Transferring control to Linux (at address 0x20000) ..." > message, it goes and does the jump and then...nothing... > > Note that the exact same Linux image boots fine from 1.1.6. My 1.1.6 can > boot both the 2.4 legacy image as well as my new 3.3 image. > > Unfortunately I've got minimal visibility into the system (My BDM interface > is being a PITA, I've got assembly-only stepping, using > CodeWarrior!!@#!@$!, in flash only. Pretty much nothing else is > functioning right at the moment), so I've been relegated to > debug-via-printf, which isn't terribly useful at the interface between > u-boot and linux. > > Through reading code, I see a huge discrepancy between how 1.1.6 and > 2012.07 starts the kernel. > > 1.1.6 uses a line: > theKernel (linux_argc, linux_argv, linux_env, 0); > > 2012.07: > /* > * Linux Kernel Parameters (passing board info data): > * sp+00: Ignore, side effect of using jsr to jump to kernel > * sp+04: ptr to board info data > * sp+08: initrd_start or 0 if no initrd > * sp+12: initrd_end - unused if initrd_start is 0 > * sp+16: Start of command line string > * sp+20: End of command line string > */ > (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end); > > Clearly different... I'd assume that U-Boot's Linux starting magic is in > sync with the current Linux kernel, but if that's the case, and these are > actually as different as they appear, then the OLD U-Boot should have a > problem starting the NEW kernel also. For grins, I grafted on the old > sequence code into the new U-Boot, but that (as expected) failed also. > > I looked at the Coldfire startup code and it looks like it corrosponds to > the same comment in U-Boot, and interestingly it seems to discard the bd_t > structure that's passed in first. > > So far I think I've figured this out: > * The FDT isn't used on Coldfire targets. > * The Coldfire code discards the bd_t data passed in through u-boot. > * Something funky is going on keeping Linux from booting, and it happens > early enough that I can't see it in printk-land. > > If it makes a difference, for some reason we load kernel at 0x20000 and > jump to 0x20000. This is a legacy of the existing project, I've tried to > change it to 0x0, but that didn't help either. I had suspected it had to do > with where the old bootloader placed itself in RAM, but it shouldn't be an > issue with the new bootloader. > > For reference: > RAM: 0x00000000, 32MB > SRAM: 0x20000000 > MBAR: 0x40000000 > Flash: 0xFFC00000, 4mb (second flash module at 0xFF800000, but U-Boot > doesn't know about that one). Image is stored at 0xFFC40000 and uses an > initrd romfs immedately after the kernel > > Basic setup and design is similar to the 5235EVB. > > CONFIG_UBOOT, MTD_UCLINUX and MTD_UCLINUX_EBSS are all Y. > > I've been bashing my head against this wall all week, so I'd love it if > anyone's got some ideas. > > Thanks, > - Steve > > 5235IWI> bootm 0xffc40000 > ## Current stack ends at 0x01f2ca2c * kernel: cmdline image address = > 0xffc40000 > ## Booting kernel from Legacy Image at ffc40000 ... > Image Name: IWI 007 > Image Type: M68K Linux Kernel Image (gzip compressed) > Data Size: 2270515 Bytes = 2.2 MiB > Load Address: 00020000 > Entry Point: 00020000 > Verifying Checksum ... OK > kernel data at 0xffc40040, len = 0x0022a533 (2270515) > ## No init Ramdisk > ramdisk start = 0x00000000, ramdisk end = 0x00000000 > Uncompressing Kernel Image ... OK > kernel loaded at 0x00020000, end = 0x00470404 > ## cmdline at 0x01f2c520 ... 0x01f2c520 > ## kernel board info at 0x01f2c4e0 > memstart = 0x00000000 > memsize = 0x02000000 > flashstart = 0xFFC00000 > flashsize = 0x00400000 > flashoffset = 0x00000000 > sramstart = 0x20000000 > sramsize = 0x00010000 > mbar = 0x40000000 > cpufreq = 150 MHz > busfreq = 75 MHz > baudrate = 57600 bps > ## initrd_high = 0xffffffff, copy_to_ram = 1 > ramdisk load start = 0x00000000, ramdisk load end = 0x00000000 > ## Transferring control to Linux (at address 00020000) ...
I am not sure why this would be, but I can say we are running uboot 2010.09 on a 5271 with 2.6.29 kernel. So at least something newer than what you had does work. We happen to use uImage format (with a kernel and a ramfs cpio archive in it). I doubt that makes a difference since the kernel works with your old uboot. Can the new uboot boot the old kernel? Which compiler are you using? Any idea what command line uboot is passing to the kernel (after all newer uboot support passing arguments to the kernel). I wonder if it could be passing arguments that are now confusing the kernel and making it loose the console. The old uboot would probably not have done that and relied entirely on the built in kernel command line from when the kernel was compiled. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
