8xx i2c refers to unspecified chip errata
> Patch was(and still is, I think) against linuxppc_2_4_devel. Don't > know your tree, is it not the same as linuxppc? Anyhow, too much time > has passed for me to remember all details and I don't have the time to > go back and do it all over again. I suggest you take the linuxppc > version, patch it and adopt it to your tree. Why the hell are there two different trees? :'( Can't we work all together for a better result? -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
a small patch to 8260_io/uart.c
Hi, Have you ever seen the strange output when the linux almost booted: VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 52k i? tty_io.c: process 1 (swapper) used obsolete /dev/cua/1 - update software to use /dev/ttyS1 tty_io.c: process 1 (init) used obsolete /dev/cua/1 - update software to use /dev/ttyS1 Something missed at the end of "52k init\n". I found at last that's because the uart driver needs to reset the serial speed in function change_speed(). It first save the enable/ disable info, and then change the smcmr, and then enable it if it was enabled before. The problem is it will stop the SMC first if the SMC was enabled before. Thus, characters missed. Ok, you don't care, just skip this mail:) I solved the problem like that: prev_mode = smcp->smc_smcmr & (SMCMR_REN | SMCMR_TEN); smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART | prev_mode; the original code is like that(around line919): prev_mode = smcp->smc_smcmr; smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART; smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN)); It works for me, maybe you have other way. Thanks, Shenrong ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx i2c refers to unspecified chip errata
> whatever your patch was against didn't match our tree very well. would > you please > resolve the differences and generate a new patch against our tree? > thanks > mds Patch was(and still is, I think) against linuxppc_2_4_devel. Don't know your tree, is it not the same as linuxppc? Anyhow, too much time has passed for me to remember all details and I don't have the time to go back and do it all over again. I suggest you take the linuxppc version, patch it and adopt it to your tree. Regards Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem with FCC under 2.4.18 kernel
Hello, I'm running the 2.4.18 linux kernel on a custom 8260 board. Sometimes I have the following problem with the ethernet 0 device while using a NFS. Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 192.168.1.65, my address is 192.168.1.145 IP-Config: Complete: device=eth0, addr=192.168.1.145, mask=255.255.255.0, gw=255.255.255.255, host=192.168.1.145, domain=, nis-domain=(none), bootserver=192.168.1.65, rootserver=192.168.1.65, rootpath=/home/targetnfs/ver_cour NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 13/2 on 192.168.1.65 Looking up port of RPC 15/1 on 192.168.1.65 VFS: Mounted root (nfs filesystem? Oops: kernel access of bad area, sig: 11 NIP: C002AF58 XER: LR: C002AEF8 SP: C010B1F0 REGS: c010b140 TRAP: 0300Not tainted MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 401F66D4, DSISR: 2000 TASK = c0109430[0] 'swapper' Last syscall: 120 last math c1f9e000 last altivec GPR00: DFFF C010B1F0 C0109430 0001 9032 C010B300 0004 C01F66C0 GPR08: C1F84000 401F66BC 0800 0003 4222 1005D7A0 34068873 FF01 GPR16: 8AC410E4 CA800C11 FF01 78E4841E 1032 0010B2F0 C0003F8C GPR24: C000506C 0400 C015 0020 C01565E8 C010B1F8 C01565E0 Call backtrace: C00C34CC C008E648 C008A5D0 C008A224 C0004F90 C00050C0 C0003F8C C00203F0 C00055F8 C0005620 C0003910 C0119718 372C Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing The last function calls are fcc_enet_rx and alloc_skb. The problem happens while I mount the NFS or later while the init phase is running. If I can enter under the busybox application, I have no more problem with the fcc device. I can increase the problem frequency if I ping on the target while the boot phase. It seems the problem happens if I receive frames during this boot phase. With an embedded ramdisk, it works fine. Does anyone already meet this situation ? Thanks in advance. G?rard ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ramdisk crash
Anders, thanks for your commit. yes, I am sure i have done it . following is my configuration file : # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set CONFIG_JFFS_FS=y CONFIG_JFFS_FS_VERBOSE=0 # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=y # CONFIG_TMPFS is not set # CONFIG_RAMFS is not set # CONFIG_ISO9660_FS is not set # CONFIG_JOLIET is not set # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set - Original Message - From: "Anders Blomdell" <[EMAIL PROTECTED]> To: "qi zhaoling" Sent: Monday, November 18, 2002 3:24 PM Subject: Re: ramdisk crash > > hi , > > I use the SELF from the denx corp to bring up my embedded linux. > > the PPCBoot and Kernel bootup sucessfully , but when i used initrd > > to mount ramdisk , the system crashed . but if i use NFS to mount = > > ramdisk > > , it's fine . > > > > i am sure: > > > > 1. I build linux kernel according to SELF > And you did remember to enable ext2 filesyste (CONFIG_EXT2_FS=y)? > > /Anders Blomdell ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
glibc 2.2.2 error
If you read the INSTALL file you would know that --with-headers should point to the linux kernel headers. I guess the path could be right but most probably not. On Mon, 2002-11-18 at 13:20, rekha gvv wrote: > > Hello, > I am setting up glibc for powerpc target but It gives > me errors .. > I have set the options > CC=powerpc-linux-gcc > ./configure --build=powerpc-linux \ > > --enable-add-ons=linuxthreads \ > > --with-headers=/usr/local/powerpc-linux/include > > But when u compile it is not able to find the headers > there ... > it gives these errors ... > so can anyone specify the right options to configure > glibc. > > > In file included from ../posix/bits/posix1_lim.h:126, > from :1: > ../linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h:36:26: > linux/limits.h: No such file or directory > make[1]: *** [../bits/stdio_lim.st] Error 1 > make[1]: Leaving directory `/usr/src/glibc-2.2.2/csu' > make: *** [csu/subdir_lib] Error 2 > > > thankyou! > > > -- Kenneth Johansson Ericsson AB Tel: +46 8 404 71 83 Borgafjordsgatan 9Fax: +46 8 404 72 72 164 80 Stockholm kenneth.johansson at etx.ericsson.se ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx i2c refers to unspecified chip errata
whatever your patch was against didn't match our tree very well. would you please resolve the differences and generate a new patch against our tree? thanks mds Tom Rini wrote: > > On Sun, Nov 17, 2002 at 10:44:40PM +0100, Joakim Tjernlund wrote: > > > > Tom + Joakim, > > > we're doing a release soon over here at sensors/i2c, > > > do you want this checked in as-is, with mods, or not at all? > > > > As-is for me. No problems reported to me. > > Works for me then. > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ -- next part -- patching file i2c-algo-8xx.c Hunk #1 FAILED at 7. Hunk #2 FAILED at 27. Hunk #3 succeeded at 74 with fuzz 2 (offset 14 lines). Hunk #5 succeeded at 157 (offset 18 lines). Hunk #6 FAILED at 177. Hunk #8 succeeded at 220 (offset 18 lines). Hunk #9 FAILED at 237. Hunk #10 succeeded at 333 (offset 2 lines). Hunk #11 FAILED at 343. Hunk #12 FAILED at 359. Hunk #13 succeeded at 439 (offset 18 lines). Hunk #14 FAILED at 464. Hunk #15 succeeded at 514 (offset 2 lines). 7 out of 15 hunks FAILED -- saving rejects to file i2c-algo-8xx.c.rej
Linker error
In message <20021118123819.75480.qmail at web8001.mail.in.yahoo.com> you wrote: > > I am trying to compile the utilities from the SELF > but it gives the error > > powerpc-linux-gcc -Wall -Os -fomit-frame-pointer > -fno-builtin -o depmod depmod.o ../util/libutil.a > ../obj/libobj.a -s > /usr/local/powerpc-linux/bin/ld: cannot open crt1.o: > No such file or directory > collect2: ld returned 1 exit status > make[1]: *** [depmod] Error 1 > - > can u please tell me how to get the crt1.o and also > the ldscript files present in > /usr/local/powerpc-linux/ldscripts. I don't know where you got your tools from, but obviously they are broken. You can download ready-to-use working tools for free - see http://www.denx.de/re/ELDK.html Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "A great many people think they are thinking when they are merely re- arranging their prejudices." - William James ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ramdisk crash
hi , I use the SELF from the denx corp to bring up my embedded linux. the PPCBoot and Kernel bootup sucessfully , but when i used initrd to mount ramdisk , the system crashed . but if i use NFS to mount = ramdisk , it's fine . i am sure: 1. I build linux kernel according to SELF 2. I build ramdisk according to SELF=20 does anybody meet this problem also ? pls give me a hand . thanks ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx i2c refers to unspecified chip errata
On Mon, Nov 18, 2002 at 08:42:48PM +0100, Jean Delvare wrote: > > > Patch was(and still is, I think) against linuxppc_2_4_devel. Don't > > know your tree, is it not the same as linuxppc? Anyhow, too much time > > has passed for me to remember all details and I don't have the time to > > go back and do it all over again. I suggest you take the linuxppc > > version, patch it and adopt it to your tree. > > Why the hell are there two different trees? :'( Can't we work all > together for a better result? Because the linuxppc tree doesn't track the whole i2c tree, as that would be quite silly. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx i2c refers to unspecified chip errata
On Mon, Nov 18, 2002 at 08:24:32PM +0100, Joakim Tjernlund wrote: > > whatever your patch was against didn't match our tree very well. would > > you please > > resolve the differences and generate a new patch against our tree? > > thanks > > mds > > Patch was(and still is, I think) against linuxppc_2_4_devel. Don't know your > tree, is > it not the same as linuxppc? Anyhow, too much time has passed for me > to remember all details and I don't have the time to go back and do it all > over again. > I suggest you take the linuxppc version, patch it and adopt it to your tree. I'll go create a proper patch vs the i2c tree later today. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.5 / Sandpoint X2
The existing switch configuration works for a 2.4 kernel. Changing S5 makes no difference. Michael Habermann wrote: > > John Traill wrote: > >> However I'm not sure if this is indicative of an error in the changes >> above or just the fact that the kernel isn't doing >> anything else but service irq's. > > > Check the switch S5, which changes the IRQ polarity. Maybe the interrupt > line is always asserted. > On a 8240 CPU, it needs reversed polarity. > -- Regards, John ___ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.5 / Sandpoint X2
On Fri, Nov 15, 2002 at 12:13:07PM +, John Traill wrote:
>
> I'm having problems getting linuxppc-2.5 running on an X2 Sandpoint system.
> Firstly there are a couple of failures
> during the build relating to changes in the interrupt handling. I've made
> the obvious changes in sandpoint_setup.c
>
> openpic_init(1,0,NULL,-1) -> openpic_init(0)
> i8259_poll() -> i8259_irq(regs)
>
> The kernel boots, mounts file system etc... but after "Freeing unused
> kernel memory: 96k init" no prompt - Initial
> debug shows that the kernel is executing some of the interrupt routines
> (sandpoint_get_irq(), openpic_irq() etc ).
> However I'm not sure if this is indicative of an error in the changes above
> or just the fact that the kernel isn't doing
> anything else but service irq's.
>
> Any help/pointers would be gratefully received.
You need more changes, no doubt. :) The following patches made an X3
work, maybe a few months ago. I didn't check them in at the time as X2
support was not working, and I hadn't figured out a good, 2.5 type
solution to the problem of the i8259 not being where expected (and Paul
had mentioned he didn't like the workaround in 2.4 for this and would
prefre something nicer for 2.5).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= arch/ppc/platforms/sandpoint.h 1.1 vs edited =
--- 1.1/arch/ppc/platforms/sandpoint.h Sun Feb 10 04:21:52 2002
+++ edited/arch/ppc/platforms/sandpoint.h Wed Nov 6 07:30:12 2002
@@ -21,6 +21,8 @@
#ifndef __PPC_PLATFORMS_SANDPOINT_H
#define __PPC_PLATFORMS_SANDPOINT_H
+#include
+
#ifdef CONFIG_SANDPOINT_X3
#define SANDPOINT_SIO_SLOT 0 /* Cascaded from EPIC IRQ 0 */
#if 0
= arch/ppc/platforms/sandpoint_pci.c 1.1 vs edited =
--- 1.1/arch/ppc/platforms/sandpoint_pci.c Sun Feb 10 04:21:52 2002
+++ edited/arch/ppc/platforms/sandpoint_pci.c Wed Nov 6 07:30:12 2002
@@ -44,17 +44,10 @@
0, 0, 0 }, /* IDSEL 11 - i8259 on Winbond */
{ 0, 0, 0, 0 }, /* IDSEL 12 - unused */
#ifdef CONFIG_SANDPOINT_X3
-#if 0 /* This is what it _should_ look like -- Dan */
- { 17, 20, 19, 18 }, /* IDSEL 13 - PCI slot 1 */
- { 18, 17, 20, 19 }, /* IDSEL 14 - PCI slot 2 */
- { 19, 18, 17, 20 }, /* IDSEL 15 - PCI slot 3 */
- { 20, 19, 18, 17 }, /* IDSEL 16 - PCI slot 4 */
-#else
{ 18, 21, 20, 19 }, /* IDSEL 13 - PCI slot 1 */
{ 19, 18, 21, 20 }, /* IDSEL 14 - PCI slot 2 */
{ 20, 19, 18, 21 }, /* IDSEL 15 - PCI slot 3 */
{ 21, 20, 19, 18 }, /* IDSEL 16 - PCI slot 4 */
-#endif
#else
{ 16, 19, 18, 17 }, /* IDSEL 13 - PCI slot 1 */
{ 17, 16, 19, 18 }, /* IDSEL 14 - PCI slot 2 */
@@ -134,15 +127,18 @@
return;
}
+/* On the sandpoint X2, we must avoid sending configuration cycles to
+ * device #12 (IDSEL addr = AD12). This has been fixed in the X3.
+ */
static int
sandpoint_exclude_device(u_char bus, u_char devfn)
{
- if ((bus == 0) && (PCI_SLOT(devfn) == SANDPOINT_HOST_BRIDGE_IDSEL)) {
+#ifndef CONFIG_SANDPOINT_X3
+ if ((bus == 0) && (PCI_SLOT(devfn) == SANDPOINT_HOST_BRIDGE_IDSEL))
return PCIBIOS_DEVICE_NOT_FOUND;
- }
- else {
+ else
+#endif
return PCIBIOS_SUCCESSFUL;
- }
}
void __init
= arch/ppc/platforms/sandpoint_setup.c 1.8 vs edited =
--- 1.8/arch/ppc/platforms/sandpoint_setup.cFri Jul 26 00:04:28 2002
+++ edited/arch/ppc/platforms/sandpoint_setup.c Wed Nov 6 07:30:13 2002
@@ -96,53 +96,28 @@
extern u_int openpic_irq(void);
extern void openpic_eoi(void);
-static voidsandpoint_halt(void);
+unsigned char __res[sizeof(bd_t)];
+static void sandpoint_halt(void);
/*
- * *** IMPORTANT ***
- *
- * The first 16 entries of 'sandpoint_openpic_initsenses[]' are there and
- * initialized to 0 on purpose. DO NOT REMOVE THEM as the 'offset' parameter
- * of 'openpic_init()' does not work for the sandpoint because the 8259
- * interrupt is NOT routed to the EPIC's IRQ 0 AND the EPIC's IRQ 0's offset is
- * the same as a normal openpic's IRQ 16 offset.
+ * Define all of the IRQ senses and polarities. Taken from the
+ * Sandpoint X3 User's manual.
*/
static u_char sandpoint_openpic_initsenses[] __initdata = {
- 0, /* 0-15 not used by EPCI but by 8259 (std PC-type IRQs) */
- 0, /* 1 */
- 0, /* 2 */
- 0, /* 3 */
- 0, /* 4 */
- 0, /* 5 */
- 0, /* 6 */
- 0, /* 7 */
- 0, /* 8 */
- 0, /* 9 */
- 0, /* 10 */
- 0, /* 11 */
- 0, /* 12 */
- 0, /* 13 */
- 0, /* 14 */
- 0, /* 15 */
#ifdef CONFIG_SANDPOINT_X3
- 1, /* 16: EPIC IRQ 0: Active Low -- SIOINT (8259) */
- 0, /* AACK! Shouldn't need this.see sandpoint_pci.c for more i
Card Services in a FADS850SAR board
Leonardo Pereira Santos wrote: > I'm configuring my kernel to support: > - hot plugable devies, > - CardBus, > - 8xx support > Have you tried a non-kernel version of pcmcia-cs? For the 850, you need to take care that PCMCIA_SLOT_B is defined, instead of PCMCIA_SLOT_A. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
USB - Interrupt problem
Hi, I have a custom PowerPC board (IBM 405 Based) with USB - OHCI compliant controller on OPB bus. I have taken SA usb driver as a refernce and enabled USB. The root hub got initialised and cat /proc/bus/usb/devices outputs "?T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= "?B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 "?D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxP "?P: Vendor= ProdID= Rev= 0.00 "?S: Product=USB OHCI Root Hub "?S: SerialNumber=ef601200 "?C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA "?I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 "?E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms but, there is no change in interrupts when I connect a USB device. cat /proc/interrupts output is CPU0 2: 119608 405IAP UIC Edge NE2000 11: 1 405IAP UIC Edge usb-ohci 29:604 405IAP UIC Edge keyboard BAD: 0 Also, whatever device I connect, it does not get listed in /proc/bus/usb/devices Could anybody please tell me as to where the problem is regarding the interrupts. Any help or suggestion would be very helpful Thank you for your time regards, Nageswari ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
glibc 2.2.2 error
Rekha: Is your kernel source tree configured? b.g. On Mon, Nov 18, 2002 at 04:20:42AM -0800, rekha gvv wrote: > > Hello, > I am setting up glibc for powerpc target but It gives > me errors .. > I have set the options > CC=powerpc-linux-gcc > ./configure --build=powerpc-linux \ > > --enable-add-ons=linuxthreads \ > > --with-headers=/usr/local/powerpc-linux/include > > But when u compile it is not able to find the headers > there ... > it gives these errors ... > so can anyone specify the right options to configure > glibc. > > > In file included from ../posix/bits/posix1_lim.h:126, > from :1: > ../linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h:36:26: > linux/limits.h: No such file or directory > make[1]: *** [../bits/stdio_lim.st] Error 1 > make[1]: Leaving directory `/usr/src/glibc-2.2.2/csu' > make: *** [csu/subdir_lib] Error 2 > > > thankyou! > > > -- Bill Gatliff Do you do embedded GNU? I do! See http://billgatliff.com for details. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
On Mon, Nov 18, 2002 at 09:19:24AM +0100, Magnus Damm wrote: > > This would be a good opportunity to switch-over to allowing the bootloader > > stick the initrd where it wants and just pass the physical pointer in via > > bi_record in all cases. It would certainly simplify these cases. > > So, the following registers passed to the kernel could change from > > * r3: ptr to board info data > * r4: initrd_start or if no initrd then 0 > * r5: initrd_end - unused if r4 is 0 > * r6: Start of command line string > * r7: End of command line string In arch/ppc/boot, only r3 is used now, FWIW. > to > > * r3: ptr to bi_record Or so, yes. Look at the archives for discussions / flamewars about bi_records. > If the initrd is going to be passed with the bi_record, and the command line > already is there, then it's just the board info left. (for the 8xx anyhow) The initrd already is, right now. And yes, the bd_t would be passed, or phased out, see the above mentioned discussions / flamewars. > Or maybe there are zillions of applications booting the kernel directly > without the bootloader.. Something _always_ loads the kernel someplace. Call it what you will, but the thing moving the kernel to 0 and pressing go is the bootloader. Oh, and see the above mentioned discissions / flamewars :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gdbserver and gdb cross debug?
"William A. Gatliff" wrote: > Jikun: > > On Mon, Nov 11, 2002 at 03:39:07PM +0800, sjk wrote: > > I am porting Linux on EP405 board. So I use gdbserver and gdb to debug > > applications,but only the first > > breakpoint could be stopped.Then if i press 'step', the program will > > execute to end straightforwardly . Any other breakpoints could not break > > the execution. > > Have you compiled the application in question with optimizations? Gdb > isn't so good at debugging optimized code. Compile with -g -O0 if you > intend to debug. I tried to compile hello.c as following: ppc_405-gcc -g -O0 -o hello hello.c Then set up the connection of gdbserver and ppc_405-gdb. The program could not be debugged step by step either. Is it possible that there is bug in ptrace.c or traps.c Thanks a lot Jikun ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
> This would be a good opportunity to switch-over to allowing the bootloader > stick the initrd where it wants and just pass the physical pointer in via > bi_record in all cases. It would certainly simplify these cases. So, the following registers passed to the kernel could change from * r3: ptr to board info data * r4: initrd_start or if no initrd then 0 * r5: initrd_end - unused if r4 is 0 * r6: Start of command line string * r7: End of command line string to * r3: ptr to bi_record If the initrd is going to be passed with the bi_record, and the command line already is there, then it's just the board info left. (for the 8xx anyhow) Or maybe there are zillions of applications booting the kernel directly without the bootloader.. / magnus Cort Dougan wrote: > > This would be a good opportunity to switch-over to allowing the bootloader > stick the initrd where it wants and just pass the physical pointer in via > bi_record in all cases. It would certainly simplify these cases. > > } > Can you give more information about where everything is loaded up at? I > } > thought this was a non-issue, but it's been a while since I tested > } > initrds. > } > } Sure. > } The first example below does not trigger the bug. > } The second one shows the bug. > } > } First example: > } > } loaded at: 0018 0023C1D0 > } board data at: 00239124 00239140 > } relocated to: 001852FC 00185318 > } zimage at: 00185880 00214ADE > } initrd at: 00215000 002388D9 > } avail ram: 0023D000 0400 > } > } gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C. > } I'm not sure about the _ALIGN() macro and how it's used, but in this case > } rec gets calculated to 0x0030. > } I thought the idea was to get a address that is aligned to the nearest > } 1-megabyte boundary. > } (2 megabyte in this case - but that would overwrite the zimage...) > } > } anyhow, the rec at 3 megabytes is inside of the available ram - good. > } > } this mail says something about typos or misuse of _ALIGN(). > } http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/ > } > } If _ALIGN() now is used correctly, then the align definition > } maybe chould be changed from > } #define _ALIGN(addr,size)(((addr)+size-1)&(~(size-1))) > } to > } #define _ALIGN(addr,size)(((addr)+(size)-1)&(~((size)-1))) > } to make sure that size is treated correctly. Or maybe it's a feature. =) > } > } Second example: > } > } loaded at: FE2226F0 FE3098C0 > } relocated to: 0018 002671D0 > } board data at: 00264124 00264140 > } relocated to: 001852E8 00185304 > } zimage at: 00185840 001CCEAB > } initrd at: 001CD000 00263A21 > } avail ram: 00268000 0400 > } > } I have not been able to output the value of zimage_size for this case, but > I'm > } sure that my initrd gets overwritten with the bi_record at 0x0020. > } We read out the initrd memory area with a BDM debugger and compared with the > } original compressed filesystem image. So rec gets set to 2 megabytes. > } This results in a initrd with bad crc. If it would help you I could get the > value > } of zimage_size, but it's on another machine and I don't have the time today. > } > } Another thing - why is the second argument (dstlen) to gunzip() always 4 > megabytes? > } Maybe it could be set to the address that the image is loaded at / > relocated to? > } (0x18 above) That way the gunzip function wouldn't overwrite the > running code, > } if I understand the dstlen argument correctly that is. > } > } I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to > match > } linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes > } recently then I don't have them. But I compared my bi_record code with the > } latest code available via rsync and they look identical. > } > } thanks / > } > } magnus > } > } Tom Rini wrote: > } > > } > On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote: > } > > } > > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c > } > > doesn't care about the initrd size. So, if you are using a initrd that > } > > crosses a megabyte-boundary you will have your initrd overwritten with > } > > the bi_record. This results in crc error when unpacking the initrd. > } > > > } > > The quick fix is to add a offset to the boot-code and to > } > > arch/ppc/kernel/setup.c. > } > > > } > > So, what's the long term solution? > } > > Passing a pointer to the kernel? > } > > } > Can you give more information about where everything is loaded up at? I > } > thought this was a non-issue, but it's been a while since I tested > } > initrds. > } > > } > -- > } > Tom Rini (TR1265) > } > http://gate.crashing.org/~trini/ > } ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gdbserver and gdb cross debug?
On Mon, 2002-11-18 at 02:43, sjk wrote: > > "William A. Gatliff" wrote: > > > Jikun: > > > > On Mon, Nov 11, 2002 at 03:39:07PM +0800, sjk wrote: > > > I am porting Linux on EP405 board. So I use gdbserver and gdb to debug > > > applications,but only the first > > > breakpoint could be stopped.Then if i press 'step', the program will > > > execute to end straightforwardly . Any other breakpoints could not break > > > the execution. > > > > Have you compiled the application in question with optimizations? Gdb > > isn't so good at debugging optimized code. Compile with -g -O0 if you > > intend to debug. > > I tried to compile hello.c as following: > > ppc_405-gcc -g -O0 -o hello hello.c > > Then set up the connection of gdbserver and ppc_405-gdb. The program could not > be debugged step by step either. > Is it possible that there is bug in ptrace.c or traps.c > > > Thanks a lot > > Jikun I have looked into this some more and could not find any problem on the kernel side(this is no guarantee that none exist). I also get the same problem with the gdb version from debian (woody)and a fresh compile of 5.2. However using the gdb 5.1.1 from ELDK 2.0 makes single step work but it steps right into functions that have no debugging information and I think step is supposed to avoid this. -- Kenneth Johansson Ericsson AB Tel: +46 8 404 71 83 Borgafjordsgatan 9Fax: +46 8 404 72 72 164 80 Stockholm kenneth.johansson at etx.ericsson.se ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.5 / Sandpoint X2
John Traill wrote: > However I'm not sure if this is indicative of an error in the changes > above or just the fact that the kernel isn't doing > anything else but service irq's. Check the switch S5, which changes the IRQ polarity. Maybe the interrupt line is always asserted. On a 8240 CPU, it needs reversed polarity. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
USB - Interrupt problem
On Mon, Nov 18, 2002 at 11:56:04AM +0530, Nageswari S wrote: > but, there is no change in interrupts when I connect a USB device. > cat /proc/interrupts output is > > >CPU0 > 2: 119608 405IAP UIC Edge NE2000 > 11: 1 405IAP UIC Edge usb-ohci > 29:604 405IAP UIC Edge keyboard > BAD: 0 > > Also, whatever device I connect, it does not get listed in > /proc/bus/usb/devices > Could anybody please tell me as to where the problem is regarding the > interrupts. > > > Any help or suggestion would be very helpful Couple options off the top of my head: 1) Check your triggering/polarity for the ohci device. Are you sure the UIC is set correctly for this device? Is this something custom hanging off the ebc? 2) You have a bug in your custom ohci HCI driver which causes it to stall before device insertion. Verify whatever status register ohci has that it is still running (I dunno, only know uhci stuffs here). Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
motorola lopec mpc7410
On Mon, Nov 18, 2002 at 09:01:14AM +0800, wrote: > > hi! > Does anybody know that there are different versions of motorola lopec > mpc7410 board? Yes, several of us have known that there are different versions of the MCG LoPEC board. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
On Fri, Nov 15, 2002 at 10:08:57AM -0700, Cort Dougan wrote: > This would be a good opportunity to switch-over to allowing the bootloader > stick the initrd where it wants and just pass the physical pointer in via > bi_record in all cases. It would certainly simplify these cases. I'm not so sure. In the case of arch/ppc/boot/ and not on OF, there aren't many places we really know are 'good' that we can throw things. I think what might help, and that we can do in 2.5 even, is allow the bootloader to put the bi_recs wherever it wants to, pass that along in r3 or r4 or so, and then in this case, we would align the bi_recs at _ALIGN(0+zimage)+_ALIGN(initrd), and if that's > 8MB, make sure that we don't allow the end of the initrd to be overwritten too. And keep in mind it's Monday, and I haven't had any coffee yet, if there's any horribly silly mistakes above :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx i2c refers to unspecified chip errata
On Sun, Nov 17, 2002 at 10:44:40PM +0100, Joakim Tjernlund wrote: > > Tom + Joakim, > > we're doing a release soon over here at sensors/i2c, > > do you want this checked in as-is, with mods, or not at all? > > As-is for me. No problems reported to me. Works for me then. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
glibc 2.2.2 error
Hello, I am setting up glibc for powerpc target but It gives me errors .. I have set the options CC=powerpc-linux-gcc ./configure --build=powerpc-linux \ > --enable-add-ons=linuxthreads \ > --with-headers=/usr/local/powerpc-linux/include But when u compile it is not able to find the headers there ... it gives these errors ... so can anyone specify the right options to configure glibc. In file included from ../posix/bits/posix1_lim.h:126, from :1: ../linuxthreads/sysdeps/unix/sysv/linux/bits/local_lim.h:36:26: linux/limits.h: No such file or directory make[1]: *** [../bits/stdio_lim.st] Error 1 make[1]: Leaving directory `/usr/src/glibc-2.2.2/csu' make: *** [csu/subdir_lib] Error 2 thankyou! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
