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
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
_______________________________________________
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
