Re: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board
On Wednesday 11 April 2007 13:47:55 [EMAIL PROTECTED] wrote: Posted a cry for help a few days ago on this issue ;) . Got a couple of answers that didn't get me any farther so I'm on another fishing expedition. Basic set up is as follows; MPC8349ITX eval board; 2.6.20.4 kernel; a ubuntu/dapper FS via NFS. The problem seems to be a random lock-up in either a DSI exception (0x300), a program exception (0x700) or a DTLB miss on store exception (0x1200). I'm sure it's not truly random (I'm sure there's probably only a single underlying problem), but it's random in how it manifests. When trying to mount the root FS via NFS, it always successfully reaches the point where it runs /sbin/init in main.c, but which script it fails in varies and it never gets to a login. I spent about 8 hours yesterday tracking down a problem on a similar board (Embedded Planet 8343M) booting Fedora 6 via NFS. Linux was getting a bit farther along than it is for you--I got a shell and could run python--but the CPU kept locking up somewhere near 0x600 or 0x1200, without a peep from the kernel. It usually occurred after a lot of memory allocation activity, so I tried tracing the out-of-memory code in the kernel, but then found I could reproduce the problem with the mtest command in U-Boot. The problem turned out to be an incorrect DDR SDRAM configuration setting in U-Boot for my board (which has no SPD EEPROM, so it's U-Boot's job to configure the memory controller). I was using CSCONFIG_ROW_BIT_12 rather than CSCONFIG_ROW_BIT_13 in CFG_DDR_CONFIG, which apparently affected the way the CPU accesses and refreshes the DRAM. I was pretty shocked that Linux was able to boot at all with a configuration bug like this. Anyway, it might be worth double-checking the DDR SDRAM code in U-Boot to make sure it's doing the right thing for the parts on your board. --Ed ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
kexec for powerpc arch 834x board?
I'm trying to get kexec to boot a powerpc arch kernel on a Freescale 834x board, but kexec-tools-1.101 seems to support only the Gamecube on 32-bit ppc. I tried hacking a memory range of 0x0003 - 0x0800 into kexec, and feeding it the vmlinux ELF image that's generated when I build the kernel, but kexec complains about 0xc000 being an invalid memory range. As far as I understand, 0xc000 is the kernel start address in virtual memory, and it's not clear how to get kexec to load the vmlinux image at a reasonable physical address (like 0x0003). Do I need to build a different powerpc image to make kexec happy, or is some hacking needed in the kexec userland program? Am I missing a more powerpc-capable version of kexec-tools? --Ed ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Serial console not working on EP8343M
On 3/13/07, Kumar Gala [EMAIL PROTECTED] wrote: Have you tried make the bootargs just console=ttyS0,115200 (or whatever your baud rate is)? I've tried that too. I just stepped through most of the console_initcall sequence with gdb and it seems like everything is getting set up properly, including irq and mmio settings for the serial devices, but still nothing gets printed. Maybe interrupts aren't getting routed? I just discovered the udbg-immortal command line option, which prevents console_init from optimistically disabling the udbg console. Debugging this problem should be a lot easier now that I can see console output past console_init. --Ed ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Serial console not working on EP8343M
I'm having trouble getting the serial console to work on an EP8343M board when using U-Boot 1.2.0 to start Linux 2.6.20.1. I'm using arch powerpc and platform MPC834x_SYS (which is perhaps wishful thinking, as my board is different, although it should at least have the same serial port configuration). The symptoms are exactly the same as those in http://ozlabs.org/pipermail/linuxppc-embedded/2006-September/024457.html: the console stops working after the call to console_init(). The suggested solution was to ensure that U-Boot is setting timebase-frequency, bus-frequency and clock-frequency and passing those properties to the kernel, and this does indeed seem to be happening in my case. I've attached the output from U-Boot (including a dump of the flat device tree), as well as my kernel config and U-Boot board settings. Any help would be appreciated. --Ed -- next part -- A non-text attachment was scrubbed... Name: u-boot.out Type: application/octet-stream Size: 16855 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070312/c87849c7/attachment.obj -- next part -- A non-text attachment was scrubbed... Name: linux.config Type: application/octet-stream Size: 19514 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070312/c87849c7/attachment-0001.obj -- next part -- A non-text attachment was scrubbed... Name: ep8343m.h Type: text/x-chdr Size: 16990 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070312/c87849c7/attachment.h -- next part -- A non-text attachment was scrubbed... Name: ep8343m.c Type: text/x-csrc Size: 16132 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070312/c87849c7/attachment.c
