Early boot problem with MPC8247 and Linux 2.6.26
Hi all, I have a custom MPC8247 based board which has been running U-boot 1.3.5 and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want to make it work using ARCH=powerpc. However, using ARCH=powerpc I have encountered a problem. Whatever I do it always appears to reset in the very early stages of booting the kernel. This is before the kernel can print anything on the console, so the last thing you see is this from the bootloader: ## Booting kernel from Legacy Image at 0040 ... Image Name: Linux-2.6.26 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1555842 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x07bb6c68 * fdt: cmdline image address = 0x0080 ## Checking for 'FDT'/'FDT Image' at 0080 * fdt: raw FDT blob ## Flattened Device Tree blob at 0080 Booting using the fdt blob at 0x80 of_flat_tree at 0x0080 size 0x0d3d ## device tree at 0x0080 ... 0x00800D3C (len=15677=0x3D3D) Loading Device Tree to 007fc000, end 007ffd3c ... OK ## Transferring control to Linux (at address ) ... Booting using OF flat tree... I am using U-boot to pass a DTB, which could be buggy or incomplete, however, I think it encounters problems before the DTB is accessed by the kernel. Using code to flash an LED I have traced execution from the entry point in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling the cache on the CPU: setup_common_caches: mfspr r11,SPRN_HID0 andi. r0,r11,HID0_DCE ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1: sync /* Chris: Reaches here. */ mtspr SPRN_HID0,r8/* enable and invalidate caches */ sync mtspr SPRN_HID0,r11 /* enable caches */ sync isync /* Chris: Never gets to here. */ blr FWIW, commenting out the lines above causes it to hang when attempting to enable the MMU, which is the next step in the process. I assume it's likely that something has already gone wrong before this point. Has anyone got any idea how the CPU could have got into a state where trying to enable the caches could cause it to reset? Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 kernel with ARCH=powerpc mode? I think it should be, but it would be good to know that someone has tried it. Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
I have a custom MPC8247 based board which has been running U-boot 1.3.5 and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want to make it work using ARCH=powerpc. However, using ARCH=powerpc I have encountered a problem. Whatever I do it always appears to reset in the very early stages of booting the kernel. could this be the hardware watchdog resetting the CPU ? Do you disable it in u-boot ? Thanks for the suggestion, but I've just double-checked and the watchdog is disabled in U-boot. In any case, I have been using an infinite loop flashing an LED to trace where execution gets to, and it never resets once it has started doing that. Any other ideas? Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Fri, 22 Aug 2008, Scott Wood wrote: Chris Skepper wrote: Using code to flash an LED I have traced execution from the entry point in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling the cache on the CPU: setup_common_caches: mfsprr11,SPRN_HID0 andi.r0,r11,HID0_DCE orir11,r11,HID0_ICE|HID0_DCE orir8,r11,HID0_ICFI bne1f/* don't invalidate the D-cache */ orir8,r8,HID0_DCI/* unless it wasn't enabled */ 1:sync /* Chris: Reaches here. */ mtsprSPRN_HID0,r8/* enable and invalidate caches */ sync mtsprSPRN_HID0,r11/* enable caches */ sync isync /* Chris: Never gets to here. */ blr FWIW, commenting out the lines above causes it to hang when attempting to enable the MMU, which is the next step in the process. How are you determining that it never gets to that point? If it's via serial I/O or similar, be aware that I/O isn't going to work when caches are enabled but the MMU is not. Hi Scott, I'm triggering an LED which is connected to port A. Are you saying that wouldn't work once the caching is enabled? Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Tue, 26 Aug 2008, Scott Wood wrote: On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote: I'm triggering an LED which is connected to port A. Are you saying that wouldn't work once the caching is enabled? It's quite possible. What other registers are in the same cache line as the LED, and are any of them non-memory-like? There are some ethernet signals, a compact flash card detect, other LEDs and a push button also on port A. Are those what you'd call non-memory-like? It's usually easiest to just trust that that part of the code works (in my experience, that's rarely where a hang actually occurs when bringing up a new board), and resume tracing after the MMU is on and you've inserted a caching-inhibited BAT entry. Where can I find out how to do that? Since I have this board working with the old ARCH=ppc, can I copy anything from there? Also, where would be a good place in the code to resume tracing? Thanks for your help so far. I see now it's probably not the code for enabling the cache that's causing the problem, it just masks my attempts at tracing using the LED. Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Tue, 26 Aug 2008, Scott Wood wrote: It's usually easiest to just trust that that part of the code works (in my experience, that's rarely where a hang actually occurs when bringing up a new board), and resume tracing after the MMU is on and you've inserted a caching-inhibited BAT entry. Where can I find out how to do that? Since I have this board working with the old ARCH=ppc, can I copy anything from there? See setup_cpm_bat in arch/powerpc/kernel/head_32.S. Also, where would be a good place in the code to resume tracing? As soon as you can set up a BAT -- though first, I would try just enabling the CPM debug console and see if you get anything from that. Thanks very much for your help so far. I tried enabling the console and didn't get anything output. So I resumed tracing and discovered it gets much further, as far as udbg_init_cpm and udbg_putc_cpm in cpm_common.c However, it never gets that first 'X' printed because it appears to hang when it gets to this bit: out_8(txbuf, c); out_be32(&cpm_udbg_txdesc[0], 0xa001); I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2? Is that likely to be correct for SMC1? (I tried looking in the MPC8272 reference manual, but couldn't find it.) Is it likely the port isn't set up properly? udbg_early_init and udbg_init_cpm get called before it probes the machine so there's been no chance to do cpm2_set_pin or anything. Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Wed, 27 Aug 2008, Scott Wood wrote:
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
Is that likely to be correct for SMC1? (I tried looking in the MPC8272
reference manual, but couldn't find it.)
The value depends on how the port was set up by firmware (or by the
bootwrapper). It should be set to wherever the descriptor is, and there
should only be one descriptor that loops back on itself.
Hi Scott,
Thanks so much for your help so far. I was able to find out this address
from the bootloader and get some output on the early debug console which
was very pleasing. It now gets as far as console_init() called from
init/main.c, which completes but then any printk seems to stall it and
you get no more output.
I am using SMC1 and have this in the DTS file for the linux,stdout-path:
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8247-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a80 0x20 0x87fc 2>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <0x1d00>;
};
Any ideas what sorts of things I should check next?
Cheers,
Chris.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Not probing devices on PowerPC MPC8247 and kernel 2.6.26
Hi All, I have an MPC8247 based board. I can get the SMC1 console working, but the other SCCx serial ports and the FCC1 ethernet doesn't work. It appears that a part of the problem is that the probe methods are not called. The "match" table stuff all looks fine and the serial ports and ethernet are defined in the .dts file. The module init function is called, but the probe methods are not reached. It seems driver_register gets called, so why doesn't something call probe? Is there likely to be some problem with the bus setup? Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Not probing devices on PowerPC MPC8247 and kernel 2.6.26
Chris Skepper ha scritto: I have an MPC8247 based board. I can get the SMC1 console working, but the other SCCx serial ports and the FCC1 ethernet doesn't work. It appears that a part of the problem is that the probe methods are not called. The "match" table stuff all looks fine and the serial ports and ethernet are defined in the .dts file. The module init function is called, but the probe methods are not reached. It seems driver_register gets called, so why doesn't something call probe? Is there likely to be some problem with the bus setup? On Wed, 10 Sep 2008, Marco Stornelli wrote: probably there's some mismatch between the device (for example some information in dts) and the driver. The match function scan for a driver for those devices but the values compared don't match the values of the drivers. Hi Marco, Thanks. But I think the "compatible" properties in the DTS are set correctly. I have "fsl,cpm2-fcc-enet" for the ethernet and "fsl,cpm2-scc-uart" which seems to be what's in the match_table. Is there something else I should check? Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Not probing devices on PowerPC MPC8247 and kernel 2.6.26
I have an MPC8247 based board. I can get the SMC1 console working, but the other SCCx serial ports and the FCC1 ethernet doesn't work. It appears that a part of the problem is that the probe methods are not called. The "match" table stuff all looks fine and the serial ports and ethernet are defined in the .dts file. The module init function is called, but the probe methods are not reached. It seems driver_register gets called, so why doesn't something call probe? Is there likely to be some problem with the bus setup? Are you calling of_platform_bus_probe() from your platform code, and do the soc and cpm nodes match the bus list (I recommend using compatible = "simple-bus")? -Scott Hi Scott, I added the simple-bus to the soc and cpm nodes and it started working just before your email arrived, but it's good to know I did the right thing. Thanks for all your help, I've now got my board working very happily with Linux 2.6.26 and arch=powerpc. In the end it was pretty much all in the dts file, but I don't think I'd have got there without your hints. Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: linux automatic logging and automatic script execution
On Tue, 28 Oct 2008, florent manni wrote: I try to make my embedded linux auto-logging and auto-executing a program after kernel loads thus I haven't got to use the terminal to logging and start my embedded program. does anyone has got a clue where I should look to set this option (I think it might be around /etc/initrd but I'm not sure). Hi Florent, You might be thinking of the file /etc/inittab or /etc/init.d/. These file(s) control what process are started by /sbin/init in different run-levels. Look at "man init" on a Linux system for more info, or read the documentation for the version of init on the system. That should enable you to start whatever you want on bootup. If init is too heavyweight you can start any other application with the the init= kernel parameter, but that's probably not recommended unless you know what you are doing. Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
