[uClinux-dev] Coldfire uClinux boot with u-boot

[Steve deRosier]

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) ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20130111/b95ee1e4/attachment.html>

[Lennart Sorensen]

Post by Steve deRosier
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
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.
theKernel (linux_argc, linux_argv, linux_env, 0);
/*
* 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.
* 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.
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.

[Kevin Nguyen]

Hi,

There are also an option for supporting u-boot parameters in kernel config.
Not sure if it helps.

Cheers

Post by Steve deRosier
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
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.
theKernel (linux_argc, linux_argv, linux_env, 0);
/*
* 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.
* 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.
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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Greg Ungerer]

Hi Steve,

Post by Steve deRosier
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
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

Post by Steve deRosier
Through reading code, I see a huge discrepancy between how 1.1.6 and
2012.07 starts the kernel.
theKernel (linux_argc, linux_argv, linux_env, 0);
/*
* 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.
* 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.
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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Philippe De Muyter]

Let's `mcf_console_putc' require a `struct uart_port *' instead of a
`struct console *'. This makes cleaner and slightly more efficient
code, and also makes mcf_console_putc easier to use for early debugging.

Signed-off-by: Philippe De Muyter <phdm at macqel.be>
---
drivers/tty/serial/mcf.c | 32 ++++++++++++++++++++------------
1 files changed, 20 insertions(+), 12 deletions(-)

Post by Greg Ungerer
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).

diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index fcd56ab..5f60382 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -473,31 +473,39 @@ int __init early_mcf_setup(struct mcf_platform_uart *platp)

/****************************************************************************/

-static void mcf_console_putc(struct console *co, const char c)
+static inline void mcf_console_wait(struct uart_port *port, unsigned char condition)
{
- struct uart_port *port = &(mcf_ports + co->index)->port;
int i;

- for (i = 0; (i < 0x10000); i++) {
- if (readb(port->membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+ for (i = 0; i < 0x10000; i++) {
+ if (readb(port->membase + MCFUART_USR) & condition)
break;
}
+}
+
+/****************************************************************************/
+
+static void mcf_console_putc(struct uart_port *port, const char c)
+{
+
+ mcf_console_wait(port, MCFUART_USR_TXREADY);
writeb(c, port->membase + MCFUART_UTB);
- for (i = 0; (i < 0x10000); i++) {
- if (readb(port->membase + MCFUART_USR) & MCFUART_USR_TXREADY)
- break;
- }
}

/****************************************************************************/

static void mcf_console_write(struct console *co, const char *s, unsigned int count)
{
- for (; (count); count--, s++) {
- mcf_console_putc(co, *s);
- if (*s == '\n')
- mcf_console_putc(co, '\r');
+ struct uart_port *port = &(mcf_ports + co->index)->port;
+
+ while (count--) {
+ unsigned char c = *s++;
+
+ mcf_console_putc(port, c);
+ if (c == '\n')
+ mcf_console_putc(port, '\r');
}
+ mcf_console_wait(port, MCFUART_USR_TXEMPTY);
}

/****************************************************************************/

[Steve deRosier]

Thanks to all that replied.

I'm still not 100% there, but finally got further. Greg, I should've just
coded up the UART output like you suggested, but I had already started
using a GPIO pin I could easily access and hooked it up to my oscope. I
did the same as you suggested, and popped it into head.S and confirmed that
u-boot was at least jumpping into the kernel. Then I used code similar to:

*((volatile u8 *)0x4010000B) = (u8)(0x01);
mdelay(10);
*((volatile u8 *)0x4010000B) = (u8)(0x00);

and used that in the C startup code to trace through. Eventually I figured
out it was getting stuck on my RTC driver (on my platform_driver_register()
call), commented that out, and it got far enough to put stuff out the
console. Then it oopsed. This was durring the second mtd map operation
(I've got two flash chips on this thing):
----
.
.
.
Flash external probe(0xff400000,4194304,2): 400000 at ff400000
bad frame format: 00000000
Modules linked in:
PC: [<00133650>] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008 SP: 0183be58 a2: 0027a8f4
d0: 00000002 d1: ff400000 d2: 00000000 d3: 00000008
d4: 0000f0f0 d5: 00000002 a0: ff400000 a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=00000000
Stack from 0183be94:
0183bf32 00000001 00000002 00000001 0183bf32 0027a8f4 00000000
00131c36
00000000 0027a8f4 0183bf32 0024c92f 0000004c 0183bf32 00000001
00000002
00000001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
00000000 00000000 0183bf32 0024c92f 0000004c 68000000 0027a8f4
01f6523a
01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
00270000
00000000 00000002 00000001 00000000 00000000 00000000 00000000
00000000
Call Trace: [<00131c36>] cfi_probe_chip+0x3c/0xaee
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<000f3acc>] memset+0x0/0x7c
[<00131b2e>] do_map_probe+0x0/0xb6
[<0013a9d2>] mtd_do_chip_probe+0x8e/0x3d8
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<00131ab0>] get_mtd_chip_driver+0x0/0x7e
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<001d7a1c>] printk+0x0/0x18
[<00131b2e>] do_map_probe+0x0/0xb6
[<00131bf4>] cfi_probe+0x10/0x16
[<00131b52>] do_map_probe+0x24/0xb6
[<001d7a1c>] printk+0x0/0x18
[<0028f9b4>] m5235_mtd_init+0xb8/0x16e
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<000200c8>] do_one_initcall+0x0/0x1d8
[<000201d8>] do_one_initcall+0x110/0x1d8
[<000200c8>] do_one_initcall+0x0/0x1d8
[<0028666a>] kernel_init+0x82/0x106
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<002865e8>] kernel_init+0x0/0x106
[<00020a3a>] kernel_thread+0x2a/0x3c

Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 <6000> f7f0 2204 2e05 e989
e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
----

So, I'm out of the woods so to speak, but not quite there yet. What I'm
totally flummoxed by is the fact that these drivers (indeed, the whole
kernel and the stuff in userspace) works just fine booted from the old
u-boot, but crap out from the new u-boot. Clearly I've done something
wrong here, but I'm not sure what or how. Based on behavior, I'm going to
be taking a very close look at the RAM allocations and stack space. Though
the stack pointer above is within my address space (32M, starting at 0, so
0x00000000 to 0x02000000). Mayhaps I'm running over my stack, hence a "bad
frame format: 00000000"? Not 100% sure of that particular message, got to
look that up.

Anyway, this is as far as I got today, tomorrow I'm going to be examining
the oops in detail and figure out why/what's going on.

I can't immagine what the difference between the old u-boot and the new one
would be that could cause the kernel to work in former case but totally
crash in the latter. I'm open to suggestions.

Thanks,
- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20130115/5180201b/attachment.html>

[Greg Ungerer]

Hi Steve,

Post by Steve deRosier
Thanks to all that replied.
I'm still not 100% there, but finally got further. Greg, I should've
just coded up the UART output like you suggested, but I had already
started using a GPIO pin I could easily access and hooked it up to my
oscope. I did the same as you suggested, and popped it into head.S and
confirmed that u-boot was at least jumpping into the kernel. Then I
*((volatile u8 *)0x4010000B) = (u8)(0x01);
mdelay(10);
*((volatile u8 *)0x4010000B) = (u8)(0x00);
and used that in the C startup code to trace through. Eventually I
figured out it was getting stuck on my RTC driver (on my
platform_driver_register() call), commented that out, and it got far
enough to put stuff out the console. Then it oopsed. This was durring

Is the newer u-boot not setting up the SoC chip selects the same?
Might explain why its accessing devices that is giving you trouble.

Regards
Greg

Post by Steve deRosier
----
.
.
.
Flash external probe(0xff400000,4194304,2): 400000 at ff400000
bad frame format: 00000000
PC: [<00133650>] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008 SP: 0183be58 a2: 0027a8f4
d0: 00000002 d1: ff400000 d2: 00000000 d3: 00000008
d4: 0000f0f0 d5: 00000002 a0: ff400000 a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=00000000
0183bf32 00000001 00000002 00000001 0183bf32 0027a8f4 00000000
00131c36
00000000 0027a8f4 0183bf32 0024c92f 0000004c 0183bf32 00000001
00000002
00000001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
00000000 00000000 0183bf32 0024c92f 0000004c 68000000 0027a8f4
01f6523a
01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
00270000
00000000 00000002 00000001 00000000 00000000 00000000 00000000
00000000
Call Trace: [<00131c36>] cfi_probe_chip+0x3c/0xaee
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<000f3acc>] memset+0x0/0x7c
[<00131b2e>] do_map_probe+0x0/0xb6
[<0013a9d2>] mtd_do_chip_probe+0x8e/0x3d8
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<00131ab0>] get_mtd_chip_driver+0x0/0x7e
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<001d7a1c>] printk+0x0/0x18
[<00131b2e>] do_map_probe+0x0/0xb6
[<00131bf4>] cfi_probe+0x10/0x16
[<00131b52>] do_map_probe+0x24/0xb6
[<001d7a1c>] printk+0x0/0x18
[<0028f9b4>] m5235_mtd_init+0xb8/0x16e
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<000200c8>] do_one_initcall+0x0/0x1d8
[<000201d8>] do_one_initcall+0x110/0x1d8
[<000200c8>] do_one_initcall+0x0/0x1d8
[<0028666a>] kernel_init+0x82/0x106
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<002865e8>] kernel_init+0x0/0x106
[<00020a3a>] kernel_thread+0x2a/0x3c
Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 <6000> f7f0 2204 2e05 e989
e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
----
So, I'm out of the woods so to speak, but not quite there yet. What I'm
totally flummoxed by is the fact that these drivers (indeed, the whole
kernel and the stuff in userspace) works just fine booted from the old
u-boot, but crap out from the new u-boot. Clearly I've done something
wrong here, but I'm not sure what or how. Based on behavior, I'm going
to be taking a very close look at the RAM allocations and stack space.
Though the stack pointer above is within my address space (32M, starting
at 0, so 0x00000000 to 0x02000000). Mayhaps I'm running over my stack,
hence a "bad frame format: 00000000"? Not 100% sure of that particular
message, got to look that up.
Anyway, this is as far as I got today, tomorrow I'm going to be
examining the oops in detail and figure out why/what's going on.
I can't immagine what the difference between the old u-boot and the new
one would be that could cause the kernel to work in former case but
totally crash in the latter. I'm open to suggestions.
Thanks,
- Steve

[Angelo Dureghello]

Hi Steve,

don't know if it can be of any help, i am running successfully last
u-boot (git pull yesterday) on a mcf5307:
There was also an issue for the coldfire family (can't check if it was
on your version now), that all the functions related to UART's in u-boot
was executing from the flash (bad relocation to ram), and has been
found/fixed by me 15 days ago.


U-Boot 2013.01-rc3-00100-gdf3ad6c-dirty (Jan 16 2013 - 00:07:29)

CPU: Freescale Coldfire MCF5307 at 90 MHz
Board: AMCORE v.001(alpha)
DRAM: 16 MiB
Flash: 4 MiB
Hit any key to stop autoboot: 0
## Booting kernel from Legacy Image at ffc20000 ...
Image Name: Linux 2.6
Image Type: M68K Linux Kernel Image (uncompressed)
Data Size: 2468868 Bytes = 2.4 MiB
Load Address: 00020000
Entry Point: 00020000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Linux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012
...


You also are oopsin'g on flash cfi detection. Are you using a custom
board or a commercial one ?

Regards,
Angelo



What u-boot version are you

uClinux/COLDFIRE(m5307)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Modified for M5307 by Dave Miller, dmiller at intellistor.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: root=/dev/mtdblock3 rootfstype=romfs init=/bin/init
video=amcorefb console=tty0 console=ttyS0,115200n8
PID hash table entries: 64 (order: -4, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 13632k/16384k RAM, (1709k kernel code, 195k data)
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.

Post by Steve deRosier
Thanks to all that replied.
I'm still not 100% there, but finally got further. Greg, I should've
just coded up the UART output like you suggested, but I had already
started using a GPIO pin I could easily access and hooked it up to my
oscope. I did the same as you suggested, and popped it into head.S
and confirmed that u-boot was at least jumpping into the kernel. Then
*((volatile u8 *)0x4010000B) = (u8)(0x01);
mdelay(10);
*((volatile u8 *)0x4010000B) = (u8)(0x00);
and used that in the C startup code to trace through. Eventually I
figured out it was getting stuck on my RTC driver (on my
platform_driver_register() call), commented that out, and it got far
enough to put stuff out the console. Then it oopsed. This was durring
----
.
.
.
Flash external probe(0xff400000,4194304,2): 400000 at ff400000
bad frame format: 00000000
PC: [<00133650>] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008 SP: 0183be58 a2: 0027a8f4
d0: 00000002 d1: ff400000 d2: 00000000 d3: 00000008
d4: 0000f0f0 d5: 00000002 a0: ff400000 a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=00000000
0183bf32 00000001 00000002 00000001 0183bf32 0027a8f4 00000000
00131c36
00000000 0027a8f4 0183bf32 0024c92f 0000004c 0183bf32 00000001
00000002
00000001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
00000000 00000000 0183bf32 0024c92f 0000004c 68000000 0027a8f4
01f6523a
01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
00270000
00000000 00000002 00000001 00000000 00000000 00000000 00000000
00000000
Call Trace: [<00131c36>] cfi_probe_chip+0x3c/0xaee
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<000f3acc>] memset+0x0/0x7c
[<00131b2e>] do_map_probe+0x0/0xb6
[<0013a9d2>] mtd_do_chip_probe+0x8e/0x3d8
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<00131ab0>] get_mtd_chip_driver+0x0/0x7e
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<001d7a1c>] printk+0x0/0x18
[<00131b2e>] do_map_probe+0x0/0xb6
[<00131bf4>] cfi_probe+0x10/0x16
[<00131b52>] do_map_probe+0x24/0xb6
[<001d7a1c>] printk+0x0/0x18
[<0028f9b4>] m5235_mtd_init+0xb8/0x16e
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<000200c8>] do_one_initcall+0x0/0x1d8
[<000201d8>] do_one_initcall+0x110/0x1d8
[<000200c8>] do_one_initcall+0x0/0x1d8
[<0028666a>] kernel_init+0x82/0x106
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<002865e8>] kernel_init+0x0/0x106
[<00020a3a>] kernel_thread+0x2a/0x3c
Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 <6000> f7f0 2204 2e05
e989 e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
----
So, I'm out of the woods so to speak, but not quite there yet. What
I'm totally flummoxed by is the fact that these drivers (indeed, the
whole kernel and the stuff in userspace) works just fine booted from
the old u-boot, but crap out from the new u-boot. Clearly I've done
something wrong here, but I'm not sure what or how. Based on
behavior, I'm going to be taking a very close look at the RAM
allocations and stack space. Though the stack pointer above is within
my address space (32M, starting at 0, so 0x00000000 to 0x02000000).
00000000"? Not 100% sure of that particular message, got to look that up.
Anyway, this is as far as I got today, tomorrow I'm going to be
examining the oops in detail and figure out why/what's going on.
I can't immagine what the difference between the old u-boot and the
new one would be that could cause the kernel to work in former case
but totally crash in the latter. I'm open to suggestions.
Thanks,
- Steve
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20130116/7642edce/attachment.html>

[Steve deRosier]

Belated update:

First thanks to everyone who helped.

Greg was right: I wasn't setting necessary chip selects up. I managed to
find that three of the drivers for our custom perhipherals were borking and
when I tried to figure out what they had in common it was a "duh" moment.
It's so funny: when you build from the start you think of chipselects and
other basic setups, but going from a working system backwards it was less
obvious to look at that.

Turns out I also had a problem with my SDRAM settings. This board has a
second SDRAM chip and thus needs both sets setup properly. Found out the
hard way that I hadn't set the second one up and thus was essentially
shadowing 32MB over 16MB of chip. Unfortunately, due to a bug in the .h
files of u-boot, it took me several days to fix. The SDRAMC_DARCn_BA()
macro was broken (patch has already been sent to the u-boot list).

In any case, thanks so much for all the help.

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20130129/d6773099/attachment.html>