Re: Coldfire uClinux boot with u-boot

Hi Steve,

On 01/12/2013 09:38 AM, Steve deRosier wrote:
> 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.

There is a couple of tricks I use to help debug in these difficult
types of scenarios.

First you really want to know if the kernel is even getting started
or not. So I throw in some raw console output into the assembler
kernel startup code (arch/m68k/platform/coldfire/head.S in this case).
For example something like this:

         moveb   #'a', %d0
         movel   #0x4000020c, %a0
         moveb   %d0, (%a0)

(Completely untested and not checked in any way :-)
Very simple, just enough to get some idea if you are getting here or
not. Note that this assumes u-boot has already setup the serial port
to the baud, etc, that you expect. And don't expect anything much to
work after this, unless you know for sure that the registers used
here (%d0 and %a0 in this case) are not being used. Oh and of course
this isn't waiting for FIFO space or anything like that - this really
is quick and dirty stuff.

If you are getting into the kernel startup code, then take the trace
up to the C code level. Code up a simple console char output routine
(use the serial driver console routines as an example).

A lot of kernel code can run before the console is enabled and output
starts to come out.

Regards
Greg


> 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
> [email protected]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev