Hi, There are also an option for supporting u-boot parameters in kernel config. Not sure if it helps.
Cheers On Sat, Jan 12, 2013 at 9:38 AM, Steve deRosier <deros...@gmail.com> 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) ... > > > > > > > > > _______________________________________________ > 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 -- Quoc-Viet (Kevin) Nguyen _______________________________________________ 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
