From pdh@colonel-panic.org Tue Mar 1 08:38:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Mar 2005 08:38:54 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:14720 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 1 Mar 2005 08:38:37 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D62u4-0000Xb-00 for ; Tue, 01 Mar 2005 08:38:52 +0000 Date: Tue, 1 Mar 2005 08:38:52 +0000 To: linux-mips@linux-mips.org Subject: [PATCH 2.6] Cobalt 1/2: tidy up PCI fixups Message-ID: <20050301083852.GA2017@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips It's not necessary to hide Galileo if we correctly mark it as a host bridge. P. -- diff -urpN linux-cvs/arch/mips/cobalt/setup.c linux-wip/arch/mips/cobalt/setup.c --- linux-cvs/arch/mips/cobalt/setup.c 2005-02-21 16:18:36.000000000 +0000 +++ linux-wip/arch/mips/cobalt/setup.c 2005-02-27 11:37:10.000000000 +0000 @@ -62,11 +62,11 @@ static void __init cobalt_timer_setup(st extern struct pci_ops gt64111_pci_ops; static struct resource cobalt_mem_resource = { - "GT64111 PCI MEM", GT64111_MEM_BASE, GT64111_MEM_END, IORESOURCE_MEM + "PCI memory", GT64111_MEM_BASE, GT64111_MEM_END, IORESOURCE_MEM }; static struct resource cobalt_io_resource = { - "GT64111 IO MEM", 0x00001000UL, GT64111_IO_END - GT64111_IO_BASE, IORESOURCE_IO + "PCI I/O", 0x1000, 0xffff, IORESOURCE_IO }; static struct resource cobalt_io_resources[] = { @@ -100,7 +100,7 @@ static int __init cobalt_setup(void) set_io_port_base(CKSEG1ADDR(GT64111_IO_BASE)); - /* IO region should cover all Galileo IO */ + /* I/O port resource must include UART and LCD/buttons */ ioport_resource.end = 0x0fffffff; /* diff -urpN linux-cvs/arch/mips/pci/fixup-cobalt.c linux-wip/arch/mips/pci/fixup-cobalt.c --- linux-cvs/arch/mips/pci/fixup-cobalt.c 2005-02-21 16:24:02.000000000 +0000 +++ linux-wip/arch/mips/pci/fixup-cobalt.c 2005-02-27 11:24:44.000000000 +0000 @@ -21,6 +21,20 @@ extern int cobalt_board_id; +static void qube_raq_galileo_early_fixup(struct pci_dev *dev) +{ + if (dev->devfn == PCI_DEVFN(0, 0) && + (dev->class >> 8) == PCI_CLASS_MEMORY_OTHER) { + + dev->class = (PCI_CLASS_BRIDGE_HOST << 8) | (dev->class & 0xff); + + printk(KERN_INFO "Galileo: fixed bridge class\n"); + } +} + +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT64111, + qube_raq_galileo_early_fixup); + static void qube_raq_via_bmIDE_fixup(struct pci_dev *dev) { unsigned short cfgword; @@ -47,8 +61,10 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V static void qube_raq_galileo_fixup(struct pci_dev *dev) { unsigned short galileo_id; - int i; + if (dev->devfn != PCI_DEVFN(0, 0)) + return; + /* Fix PCI latency-timer and cache-line-size values in Galileo * host bridge. */ @@ -73,7 +89,7 @@ static void qube_raq_galileo_fixup(struc pci_read_config_word(dev, PCI_REVISION_ID, &galileo_id); galileo_id &= 0xff; /* mask off class info */ - printk("Galileo ID: %u\n", galileo_id); + printk(KERN_INFO "Galileo: revision %u\n", galileo_id); #if 0 if (galileo_id >= 0x10) { @@ -88,18 +104,9 @@ static void qube_raq_galileo_fixup(struc /* Old Galileo, assumes PCI STOP line to VIA is disconnected. */ GALILEO_OUTL(0xffff, GT_PCI0_TOR_OFS); } - - /* - * hide Galileo from the kernel's PCI resource assignment. The BARs - * on Galileo will already have been set up by the boot loader to - * match the DRAM configuration so we don't want them being monkeyed - * around with. - */ - for (i = 0; i < DEVICE_COUNT_RESOURCE; ++i) - dev->resource[i].start = dev->resource[i].end = dev->resource[i].flags = 0; } -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL, PCI_ANY_ID, +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT64111, qube_raq_galileo_fixup); static char irq_tab_cobalt[] __initdata = { From pdh@colonel-panic.org Tue Mar 1 08:41:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Mar 2005 08:41:38 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:16000 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 1 Mar 2005 08:41:21 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D62wk-0000Xz-00; Tue, 01 Mar 2005 08:41:38 +0000 Date: Tue, 1 Mar 2005 08:41:38 +0000 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2.6] Cobalt 2/2: add support for Qube2700 Message-ID: <20050301084138.GB2017@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips On Qube2700 Galileo hangs if we access slot #6. Make console serial port initialisation dependent on unit type. P. -- diff -urpN linux-wip/arch/mips/cobalt/setup.c linux-qube1/arch/mips/cobalt/setup.c --- linux-wip/arch/mips/cobalt/setup.c 2005-02-27 17:21:23.000000000 +0000 +++ linux-qube1/arch/mips/cobalt/setup.c 2005-02-27 16:25:20.000000000 +0000 @@ -13,6 +13,8 @@ #include #include #include +#include +#include #include #include @@ -21,6 +23,7 @@ #include #include #include +#include #include @@ -89,6 +92,7 @@ static struct pci_controller cobalt_pci_ static int __init cobalt_setup(void) { + static struct uart_port uart; unsigned int devfn = PCI_DEVFN(COBALT_PCICONF_VIA, 0); int i; @@ -127,6 +131,21 @@ static int __init cobalt_setup(void) register_pci_controller(&cobalt_pci_controller); #endif +#ifdef CONFIG_SERIAL_8250 + if (cobalt_board_id > COBALT_BRD_ID_RAQ1) { + + uart.line = 0; + uart.type = PORT_UNKNOWN; + uart.uartclk = 18432000; + uart.irq = COBALT_SERIAL_IRQ; + uart.flags = STD_COM_FLAGS; + uart.iobase = 0xc800000; + uart.iotype = UPIO_PORT; + + early_serial_setup(&uart); + } +#endif + return 0; } diff -urpN linux-wip/arch/mips/pci/fixup-cobalt.c linux-qube1/arch/mips/pci/fixup-cobalt.c --- linux-wip/arch/mips/pci/fixup-cobalt.c 2005-02-27 17:21:23.000000000 +0000 +++ linux-qube1/arch/mips/pci/fixup-cobalt.c 2005-02-27 16:44:57.000000000 +0000 @@ -109,6 +109,15 @@ static void qube_raq_galileo_fixup(struc DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT64111, qube_raq_galileo_fixup); +static char irq_tab_qube1[] __initdata = { + [COBALT_PCICONF_CPU] = 0, + [COBALT_PCICONF_ETH0] = COBALT_QUBE1_ETH0_IRQ, + [COBALT_PCICONF_RAQSCSI] = COBALT_SCSI_IRQ, + [COBALT_PCICONF_VIA] = 0, + [COBALT_PCICONF_PCISLOT] = COBALT_QUBE_SLOT_IRQ, + [COBALT_PCICONF_ETH1] = 0 +}; + static char irq_tab_cobalt[] __initdata = { [COBALT_PCICONF_CPU] = 0, [COBALT_PCICONF_ETH0] = COBALT_ETH0_IRQ, @@ -129,6 +138,9 @@ static char irq_tab_raq2[] __initdata = int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { + if (cobalt_board_id < COBALT_BRD_ID_QUBE2) + return irq_tab_qube1[slot]; + if (cobalt_board_id == COBALT_BRD_ID_RAQ2) return irq_tab_raq2[slot]; diff -urpN linux-wip/arch/mips/pci/ops-gt64111.c linux-qube1/arch/mips/pci/ops-gt64111.c --- linux-wip/arch/mips/pci/ops-gt64111.c 2003-11-13 16:55:07.000000000 +0000 +++ linux-qube1/arch/mips/pci/ops-gt64111.c 2005-02-27 16:42:29.000000000 +0000 @@ -20,13 +20,21 @@ /* * Accessing device 31 hangs the GT64120. Not sure if this will also hang * the GT64111, let's be paranoid for now. + * + * Accessing device COBALT_PCICONF_CPU hangs early units. */ static inline int pci_range_ck(struct pci_bus *bus, unsigned int devfn) { - if (bus->number == 0 && devfn == PCI_DEVFN(31, 0)) - return -1; + unsigned slot; - return 0; + if (bus->number == 0) { + + slot = PCI_SLOT(devfn); + if (slot != COBALT_PCICONF_CPU && slot < 31) + return 0; + } + + return -1; } static int gt64111_pci_read_config(struct pci_bus *bus, unsigned int devfn, diff -urpN linux-wip/drivers/net/tulip/de2104x.c linux-qube1/drivers/net/tulip/de2104x.c --- linux-wip/drivers/net/tulip/de2104x.c 2005-02-07 02:54:50.000000000 +0000 +++ linux-qube1/drivers/net/tulip/de2104x.c 2005-02-27 17:03:09.000000000 +0000 @@ -1787,10 +1787,15 @@ static void __init de21041_get_srom_info /* DEC now has a specification but early board makers just put the address in the first EEPROM locations. */ /* This does memcmp(eedata, eedata+16, 8) */ + +#ifndef CONFIG_MIPS_COBALT + for (i = 0; i < 8; i ++) if (ee_data[i] != ee_data[16+i]) sa_offset = 20; +#endif + /* store MAC address */ for (i = 0; i < 6; i ++) de->dev->dev_addr[i] = ee_data[i + sa_offset]; diff -urpN linux-wip/include/asm-mips/cobalt/cobalt.h linux-qube1/include/asm-mips/cobalt/cobalt.h --- linux-wip/include/asm-mips/cobalt/cobalt.h 2005-02-21 16:18:36.000000000 +0000 +++ linux-qube1/include/asm-mips/cobalt/cobalt.h 2005-02-27 16:44:36.000000000 +0000 @@ -29,6 +29,7 @@ #define COBALT_SCC_IRQ 19 /* pre-production has 85C30 */ #define COBALT_RAQ_SCSI_IRQ 19 #define COBALT_ETH0_IRQ 19 +#define COBALT_QUBE1_ETH0_IRQ 20 #define COBALT_ETH1_IRQ 20 #define COBALT_SERIAL_IRQ 21 #define COBALT_SCSI_IRQ 21 diff -urpN linux-wip/include/asm-mips/serial.h linux-qube1/include/asm-mips/serial.h --- linux-wip/include/asm-mips/serial.h 2004-11-09 18:28:25.000000000 +0000 +++ linux-qube1/include/asm-mips/serial.h 2005-02-27 16:23:11.000000000 +0000 @@ -78,16 +78,6 @@ #define JAZZ_SERIAL_PORT_DEFNS #endif -#ifdef CONFIG_MIPS_COBALT -#include -#define COBALT_BASE_BAUD (18432000 / 16) -#define COBALT_SERIAL_PORT_DEFNS \ - /* UART CLK PORT IRQ FLAGS */ \ - { 0, COBALT_BASE_BAUD, 0xc800000, COBALT_SERIAL_IRQ, STD_COM_FLAGS }, /* ttyS0 */ -#else -#define COBALT_SERIAL_PORT_DEFNS -#endif - /* * Both Galileo boards have the same UART mappings. */ @@ -424,7 +414,6 @@ #endif /* CONFIG_SGI_IP32 */ #define SERIAL_PORT_DFNS \ - COBALT_SERIAL_PORT_DEFNS \ DDB5477_SERIAL_PORT_DEFNS \ EV96100_SERIAL_PORT_DEFNS \ EXTRA_SERIAL_PORT_DEFNS \ From jgreen@users.sourceforge.net Wed Mar 2 22:26:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Mar 2005 22:26:18 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:53161 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Mar 2005 22:26:00 +0000 Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35]) by mail-relay.infostations.net (Postfix) with ESMTP id EF02D9F7CB for ; Wed, 2 Mar 2005 14:25:53 -0800 (PST) Received: from host-66-81-128-16.rev.o1.com ([66.81.128.16]) by seriyu.infostations.net with esmtp (Exim 4.41 #1) id 1D6cHz-0007Hz-Kl for ; Wed, 02 Mar 2005 14:25:58 -0800 Subject: iptable_nat oops From: Josh Green To: linux-mips@linux-mips.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xfbS5sb98PjtsvN8jDwx" Date: Wed, 02 Mar 2005 14:27:51 -0800 Message-Id: <1109802471.13452.20.camel@SillyPuddy.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jgreen@users.sourceforge.net Precedence: bulk X-list: linux-mips --=-xfbS5sb98PjtsvN8jDwx Content-Type: multipart/mixed; boundary="=-KD1/v3f9wG6oAY/fk5cb" --=-KD1/v3f9wG6oAY/fk5cb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I sent an email a few weeks back about a problem with iptables and NAT. This problem appears to be related to what order I insert modules, so its likely a memory location issue. I've attached a couple of oops output dumps. I gave up on trying to get ksymoops to function completely (no /proc/ksyms on my target and I read something about it being deprecated??), still I hope these dumps are useful. I'm not sure yet whether its a mips specific problem, but I thought maybe I'd see if anyone else has experienced this. My target system is an AMD Alchemy db1100, I'm using mips-linux CVS from a month ago or so (2.6.11 rc2), gcc 3.4.3 and uclibc. In the problem case I get the following output when trying to modify the 'nat' table with iptables: # iptables -t nat -F iptables v1.3.0: can't initialize iptables table `nat': Memory allocation problem Perhaps iptables or your kernel needs to be upgraded. strace output of iptables shows that there is an attempt to mmap over 1.6GB of memory. old_mmap(NULL, 1651212288, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, 0, 0) =3D -1 ENOMEM (Cannot allocate memory) Oops occur as soon as any IP traffic is attempted over the interfaces. I've attached 2 variations, the first 'nat2_oops.txt' occurred after a client machine attempted to get a DHCP lease, the second 'nat3_oops.txt' is when attempting a ping from the target system. In both cases it seems ip_nat_rule_find() and ip_nat_fn() are common functions, so I suspect the nat table hasn't been initialized correctly or something else is trashing some memory. Let me know if there is a more appropriate place for this bug report. Josh Green --=-KD1/v3f9wG6oAY/fk5cb Content-Disposition: attachment; filename=nat2_oops.txt Content-Transfer-Encoding: base64 Content-Type: text/plain; name=nat2_oops.txt; charset=ISO-8859-1 IyBDUFUgMCBVbmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFs IGFkZHJlc3MgMjE4YTc2MDgsIGVwYw0KPT0gYzAwNzUxMTAsIHJhID09IGMwMThiZDEwDQpPb3Bz IGluIGFyY2gvbWlwcy9tbS9mYXVsdC5jOjpkb19wYWdlX2ZhdWx0LCBsaW5lIDE2NlsjMV06DQpD cHUgMA0KJCAwICAgOiAwMDAwMDAwMCAxMDAwZmMwMCBjMDE4MTAwMCAyOTg2N2ZiMg0KJCA0ICAg OiA4MTBjN2FlMCBjMDE4MTAwMCA4M2M0NzAwMCAwMDAwMDAwMA0KJCA4ICAgOiA4MTBjN2FlMCBm ZmZmZmZmZiA4MDMzYmMwMCBjMDFlYTkyOA0KJDEyICAgOiAwMDAwMDAwMCAwMDIwMDIwMCAwMDEw MDEwMCA4MTE5YjlmNA0KJDE2ICAgOiAyMThhNzViNCA4MTJjN2QyMCA4M2NmMzg1NCA4MDMzYmNl MA0KJDIwICAgOiA4MDMzYmNlMCA4M2M0NzAwMCBjMDE4MTA0MCBjMDA3Y2VhMA0KJDI0ICAgOiAw MDAwMDAwMSBjMDFlNTgzMA0KJDI4ICAgOiA4MDMzYTAwMCA4MDMzYmI1MCA4M2M0NzAwMCBjMDE4 YmQxMA0KSGkgICAgOiAwMDAwMDAwMA0KTG8gICAgOiAwMDAwMGNlNA0KZXBjICAgOiBjMDA3NTEx MCBpcHRfZG9fdGFibGUrMHhiOC8weDQ3OCBbaXBfdGFibGVzXSAgICAgTm90IHRhaW50ZWQNCnJh ICAgIDogYzAxOGJkMTAgaXBfbmF0X3J1bGVfZmluZCsweDM0LzB4ZjggW2lwdGFibGVfbmF0XQ0K U3RhdHVzOiAxMDAwZmMwMyAgICBLRVJORUwgRVhMIElFDQpDYXVzZSA6IDAwODAwMDA4DQpCYWRW QSA6IDIxOGE3NjA4DQpQcklkICA6IDAyMDMwMjA0DQpNb2R1bGVzIGxpbmtlZCBpbjogaXB0X01B U1FVRVJBREUgaXB0X3N0YXRlIGlwX25hdF9pcmMgaXBfbmF0X2Z0cCBpcF9jb25udHJhY2tfaXJj IGlwX2Nvbm50cmFja19mdHAgaXB0YWJsZV9uYXQgaXBfY29ubnRyYWNrIGJyaWRnZSBpcHRhYmxl X2ZpbHRlciBob3N0YXBfY3MgaXBfdGFibGVzIGhvc3RhcF9jcnlwdF93ZXAgaG9zdGFwIHBjbWNp YSBhdTF4MDBfc3MgcGNtY2lhX2NvcmUNClByb2Nlc3Mgc3dhcHBlciAocGlkOiAwLCB0aHJlYWRp bmZvPTgwMzNhMDAwLCB0YXNrPTgwMzNjMDAwKQ0KU3RhY2sgOiAwMDAwZmZmZiAwMDIwMDIwMCAw MDEwMDEwMCA4MTE5YjlmNCAxMDAwZmMwMSA4MDMzYmMxOCAwMDAwMDAwMCAwMDAwMDAwMA0KICAg ICAgICAwMDAwMDAwMCAyOTg2N2ZiMiAwMDAwMDAwMCA4MTJjN2QyMCAwMDAwMDAwMSA4MDMzYmNl MCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICA4M2M0NzAwMCAwMDAwMDAwMiBjMDFkODhiNCBj MDE4YmQxMCAxMDAwZmMwMyAwMDAwMDAwMCA4MTJjN2QyMCAwMDAwMDAwMA0KICAgICAgICBjMDE5 MDZjMCAwMDAwMDAwMCBjMDFlYWMzMCAwMDAwMDAwMCA4MDMzYmMxYyA4MDMzYmJlOCA4MTJjN2Qy MCAwMDAwMDAwMg0KICAgICAgICBjMDE4YjE0YyBmZmZmZmZmZiAzNjZmMDIwMCAwMjAwYjU1NSBj MDFlYWMzMCAwMDAwMDAwMCA4MTJjN2QyMCA4MTJjN2Q5OA0KICAgICAgICAuLi4NCkNhbGwgVHJh Y2U6DQogWzxjMDFkODhiND5dIGJyX25mX3ByZV9yb3V0aW5nX2ZpbmlzaCsweDAvMHg1NjAgW2Jy aWRnZV0NCiBbPGMwMThiZDEwPl0gaXBfbmF0X3J1bGVfZmluZCsweDM0LzB4ZjggW2lwdGFibGVf bmF0XQ0KIFs8YzAxOGIxNGM+XSBpcF9uYXRfZm4rMHgxNGMvMHgyYWMgW2lwdGFibGVfbmF0XQ0K IFs8YzAxOGIyZWM+XSBpcF9uYXRfaW4rMHg0MC8weDE3NCBbaXB0YWJsZV9uYXRdDQogWzxjMDFk ODhiND5dIGJyX25mX3ByZV9yb3V0aW5nX2ZpbmlzaCsweDAvMHg1NjAgW2JyaWRnZV0NCiBbPDgw MjdmOGI0Pl0gbmZfaXRlcmF0ZSsweGJjLzB4MTVjDQogWzw4MDI3ZjhiND5dIG5mX2l0ZXJhdGUr MHhiYy8weDE1Yw0KIFs8YzAxZDg4YjQ+XSBicl9uZl9wcmVfcm91dGluZ19maW5pc2grMHgwLzB4 NTYwIFticmlkZ2VdDQogWzxjMDFkODhiND5dIGJyX25mX3ByZV9yb3V0aW5nX2ZpbmlzaCsweDAv MHg1NjAgW2JyaWRnZV0NCiBbPDgwMjgwMjA4Pl0gbmZfaG9va19zbG93KzB4OWMvMHgyMDANCiBb PDgwMjcwNDcwPl0gZGV2X3F1ZXVlX3htaXQrMHgyZTgvMHgzM2MNCiBbPDgwMjY4YzU0Pl0ga2Zy ZWVfc2tibWVtKzB4MTQvMHgzMA0KIFs8ODAyNjc5OTg+XSBhbGxvY19za2IrMHg1OC8weGY0DQog WzxjMDFkODhiND5dIGJyX25mX3ByZV9yb3V0aW5nX2ZpbmlzaCsweDAvMHg1NjAgW2JyaWRnZV0N CiBbPGMwMWQzOGRjPl0gYnJfaGFuZGxlX2ZyYW1lX2ZpbmlzaCsweDAvMHgyMDQgW2JyaWRnZV0N CiBbPGMwMWQ5NzA0Pl0gYnJfbmZfcHJlX3JvdXRpbmcrMHg4N2MvMHg5MjAgW2JyaWRnZV0NCiBb PGMwMWQ4OGI0Pl0gYnJfbmZfcHJlX3JvdXRpbmdfZmluaXNoKzB4MC8weDU2MCBbYnJpZGdlXQ0K IFs8ODAyN2Y4YjQ+XSBuZl9pdGVyYXRlKzB4YmMvMHgxNWMNCiBbPDgwMjA3Njg4Pl0gbWVtY21w KzB4MC8weDMwDQogWzxjMDFkMzhkYz5dIGJyX2hhbmRsZV9mcmFtZV9maW5pc2grMHgwLzB4MjA0 IFticmlkZ2VdDQogWzxjMDFkMzhkYz5dIGJyX2hhbmRsZV9mcmFtZV9maW5pc2grMHgwLzB4MjA0 IFticmlkZ2VdDQogWzw4MDI4MDIwOD5dIG5mX2hvb2tfc2xvdysweDljLzB4MjAwDQogWzxjMDFk NjA1MD5dIGJyX3NlbmRfY29uZmlnX2JwZHUrMHgxZGMvMHgyMDAgW2JyaWRnZV0NCiBbPGMwMWQz OGRjPl0gYnJfaGFuZGxlX2ZyYW1lX2ZpbmlzaCsweDAvMHgyMDQgW2JyaWRnZV0NCiBbPGMwMWQz ZDRjPl0gYnJfaGFuZGxlX2ZyYW1lKzB4MjZjLzB4MjkwIFticmlkZ2VdDQogWzxjMDFkNGViOD5d IGJyX3RyYW5zbWl0X2NvbmZpZysweDAvMHgxNzggW2JyaWRnZV0NCiBbPGMwMWQzOGRjPl0gYnJf aGFuZGxlX2ZyYW1lX2ZpbmlzaCsweDAvMHgyMDQgW2JyaWRnZV0NCiBbPDgwMjcwZGIwPl0gbmV0 aWZfcmVjZWl2ZV9za2IrMHgxZTQvMHg0ZTQNCiBbPGMwMTlhZDEwPl0gaGZhMzg0eF9jbWRfY2Fs bGJhY2srMHg1Yy8weDQ2NCBbaG9zdGFwX2NzXQ0KIFs8ODAyNzExYzA+XSBwcm9jZXNzX2JhY2ts b2crMHgxMTAvMHgyZjANCiBbPGMwMTljOTZjPl0gaG9zdGFwX3J4X3Rhc2tsZXQrMHgyMjgvMHgy YmMgW2hvc3RhcF9jc10NCiBbPDgwMjcxNDZjPl0gbmV0X3J4X2FjdGlvbisweGNjLzB4Mjk0DQog Wzw4MDEyYzgxOD5dIHRhc2tsZXRfYWN0aW9uKzB4YzQvMHgxOTQNCiBbPDgwMTQ3NmQ0Pl0gaGFu ZGxlX0lSUV9ldmVudCsweDdjLzB4MTM0DQogWzw4MDEyYzFkYz5dIF9fZG9fc29mdGlycSsweDhj LzB4MTRjDQogWzw4MDE0NzkyMD5dIF9fZG9fSVJRKzB4MTk0LzB4MWI0DQogWzw4MDM4MDAwMD5d IGlnbXBfbWNfcHJvY19pbml0KzB4NGMvMHg3NA0KIFs8ODAzODAwMDA+XSBpZ21wX21jX3Byb2Nf aW5pdCsweDRjLzB4NzQNCiBbPDgwMTJjMzI4Pl0gZG9fc29mdGlycSsweDhjLzB4YjgNCiBbPDgw MzgwMDAwPl0gaWdtcF9tY19wcm9jX2luaXQrMHg0Yy8weDc0DQogWzw4MDEwMGUyYz5dIGF1MTAw MF9JUlErMHgxNmMvMHgxYTANCiBbPDgwMzdjNmEwPl0gdnR5X2luaXQrMHhmYy8weDEyOA0KIFs8 ODAzODAwMDA+XSBpZ21wX21jX3Byb2NfaW5pdCsweDRjLzB4NzQNCiBbPDgwMjZiN2I4Pl0gZGF0 YWdyYW1fcG9sbCsweDAvMHgxOTgNCiBbPDgwMTA0YTkwPl0gY3B1X2lkbGUrMHg0OC8weDUwDQog Wzw4MDEwNGE2ND5dIGNwdV9pZGxlKzB4MWMvMHg1MA0KIFs8ODAyMDM1ZDA+XSBpZHJfY2FjaGVf Y3RvcisweDAvMHhjDQogWzw4MDM4MDAwMD5dIGlnbXBfbWNfcHJvY19pbml0KzB4NGMvMHg3NA0K IFs8ODAzNjU3YWM+XSBzdGFydF9rZXJuZWwrMHgyMDAvMHgyYzANCiBbPDgwMzY1MGZjPl0gdW5r bm93bl9ib290b3B0aW9uKzB4MC8weDMxMA0KDQoNCkNvZGU6IGFmYTMwMDI0ICAwMmM0ODAyMSAg OGU4NDAwMDAgPDhlMDMwMDU0PiA4YzgyMDA4NCAgMDA0MzEwMjUgIGFjODIwMDg0ICA5MjA5MDA1 MyAgMDAwOTEwYzINCktlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBBaWVlLCBraWxsaW5nIGlu dGVycnVwdCBoYW5kbGVyIQ0KIDw2PndpZmkxOiBTVyBUSUNLIHN0dWNrPyBiaXRzPTB4MCBFdlN0 YXQ9ODAwMCBJbnRFbj1lMDlmDQo= --=-KD1/v3f9wG6oAY/fk5cb Content-Disposition: attachment; filename=nat3_oops.txt Content-Transfer-Encoding: base64 Content-Type: text/plain; name=nat3_oops.txt; charset=ISO-8859-1 VW5oYW5kbGVkIGtlcm5lbCB1bmFsaWduZWQgYWNjZXNzIGluIGFyY2gvbWlwcy9rZXJuZWwvdW5h bGlnbmVkLmM6OmVtdWxhdGVfbG9hZF9zdG9yZV9pbnNuLCBsaW5lIDQ3NVsjMV06DQpDcHUgMA0K JCAwICAgOiAwMDAwMDAwMCAxMDAwZmMwMCBjMDE4MTAwYyA0MDUyNTA0MA0KJCA0ICAgOiA4M2Vl N2JjMCBjMDE4MTAwMCAwMDAwMDAwMCA4M2NkMWMwMA0KJCA4ICAgOiAwMDAwMDAwMSAwMTAxYThj MCA4M2VkZGI2MCBjMDFlZTkyOA0KJDEyICAgOiAwMDAwMDAwMCAwMDIwMDIwMCAwMDEwMDEwMCA4 MTE5YjlmNA0KJDE2ICAgOiAzMzE4ODBiNSA4M2VkYWQyMCA4MTMxY2ExMCA4M2VkZGM0MA0KJDIw ICAgOiA4M2VkZGM0MCBjMDA3Y2VhMCBjMDE4MTA0MCA4M2NkMWMwMA0KJDI0ICAgOiAwMDAwMDAw MSBjMDFlOWQyOA0KJDI4ICAgOiA4M2VkYzAwMCA4M2VkZGFiMCAwMDAwMDAwMCBjMDE4YmQxMA0K SGkgICAgOiAwMDAwMDAwMA0KTG8gICAgOiAwMDAwMGNlNA0KZXBjICAgOiBjMDA3NTExMCBpcHRf ZG9fdGFibGUrMHhiOC8weDQ3OCBbaXBfdGFibGVzXSAgICAgTm90IHRhaW50ZWQNCnJhICAgIDog YzAxOGJkMTAgaXBfbmF0X3J1bGVfZmluZCsweDM0LzB4ZjggW2lwdGFibGVfbmF0XQ0KU3RhdHVz OiAxMDAwZmMwMyAgICBLRVJORUwgRVhMIElFDQpDYXVzZSA6IDAwODAwMDEwDQpCYWRWQSA6IDMz MTg4MTA5DQpQcklkICA6IDAyMDMwMjA0DQpNb2R1bGVzIGxpbmtlZCBpbjogaXB0X01BU1FVRVJB REUgaXB0X3N0YXRlIGlwX25hdF9pcmMgaXBfbmF0X2Z0cCBpcF9jb25udHJhY2tfaXJjIGlwX2Nv bm50cmFja19mdHAgaXB0YWJsZV9uYXQgaXBfY29ubnRyYWNrIGJyaWRnZSBob3N0YXBfY3MgaXB0 YWJsZV9maWx0ZXIgaXBfdGFibGVzIGhvc3RhcF9jcnlwdF93ZXAgaG9zdGFwIHBjbWNpYSBhdTF4 MDBfc3MgcGNtY2lhX2NvcmUNClByb2Nlc3MgcGluZyAocGlkOiAxMDI5LCB0aHJlYWRpbmZvPTgz ZWRjMDAwLCB0YXNrPTgxM2JmNDg4KQ0KU3RhY2sgOiAwMDAwMDAyMCAwMDAwMDAwMyAwMDAwMDAy MCA4MDE1MTA5NCAwMDAwMDAwMCA4MDI3N2EyMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAw MDAwMDAwMCA0MDUyNTA0MCAwMDAwMDAwMyA4M2VkYWQyMCAwMDAwMDAwMSA4M2VkZGM0MCAwMDAw MDAwMyA4M2NkMWMwMA0KICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMiA4MDI5ODdhMCBjMDE4YmQx MCBjMDFlZWM3MCAwMDAwMDAwMyA4M2VkYWQyMCA4M2NkMWMwMA0KICAgICAgICBjMDE5MDZjMCAw MDAwMDAwMCBjMDFlZWM3MCAwMDAwMDAwMyA4M2VkZGI3YyA4M2VkZGI0OCA4M2VkYWQyMCAwMDAw MDAwMg0KICAgICAgICBjMDE4YjE0YyA4M2VkZGI1OCA4M2VkZGJkOCA4MDI4ZmNjYyBjMDFlZWM3 MCAwMDAwMGUwMCA4M2VkYWQyMCA4M2VkYWQ5OA0KICAgICAgICAuLi4NCkNhbGwgVHJhY2U6DQog Wzw4MDE1MTA5ND5dIF9fZ2V0X2ZyZWVfcGFnZXMrMHgyYy8weDZjDQogWzw4MDI3N2EyMD5dIG5l aWdoX2NyZWF0ZSsweDYwNC8weDg3MA0KIFs8ODAyOTg3YTA+XSBkc3Rfb3V0cHV0KzB4MC8weDUw DQogWzxjMDE4YmQxMD5dIGlwX25hdF9ydWxlX2ZpbmQrMHgzNC8weGY4IFtpcHRhYmxlX25hdF0N CiBbPGMwMThiMTRjPl0gaXBfbmF0X2ZuKzB4MTRjLzB4MmFjIFtpcHRhYmxlX25hdF0NCiBbPDgw MjhmY2NjPl0gcnRfc2V0X25leHRob3ArMHg0OC8weDFhMA0KIFs8YzAxOGI1OWM+XSBpcF9uYXRf bG9jYWxfZm4rMHg4OC8weGZjIFtpcHRhYmxlX25hdF0NCiBbPDgwMjk4N2EwPl0gZHN0X291dHB1 dCsweDAvMHg1MA0KIFs8ODAyN2Y4YjQ+XSBuZl9pdGVyYXRlKzB4YmMvMHgxNWMNCiBbPDgwMjdm OGI0Pl0gbmZfaXRlcmF0ZSsweGJjLzB4MTVjDQogWzw4MDI5ODdhMD5dIGRzdF9vdXRwdXQrMHgw LzB4NTANCiBbPDgwMjk4N2EwPl0gZHN0X291dHB1dCsweDAvMHg1MA0KIFs8ODAyODAyMDg+XSBu Zl9ob29rX3Nsb3crMHg5Yy8weDIwMA0KIFs8ODAyOWI1NmM+XSBpcF9hcHBlbmRfZGF0YSsweDY4 MC8weGEyNA0KIFs8ODAyOTg3YTA+XSBkc3Rfb3V0cHV0KzB4MC8weDUwDQogWzw4MDI5YzNhND5d IGlwX3B1c2hfcGVuZGluZ19mcmFtZXMrMHg1YjgvMHg2NzANCiBbPDgwMjk4N2EwPl0gZHN0X291 dHB1dCsweDAvMHg1MA0KIFs8ODAyYmMzNmM+XSByYXdfc2VuZG1zZysweDFjNC8weDlhOA0KIFs8 ODAyYmMzNDg+XSByYXdfc2VuZG1zZysweDFhMC8weDlhOA0KIFs8ODAyOWFlMzA+XSBpcF9nZW5l cmljX2dldGZyYWcrMHgwLzB4YmMNCiBbPDgwMTRiYzg4Pl0gZmlsZW1hcF9ub3BhZ2UrMHg1ZDQv MHg2ZTANCiBbPDgwMjYxOWZjPl0gc29ja19zZW5kbXNnKzB4YWMvMHhmMA0KIFs8ODAxNjE0ZWM+ XSBkb19ub19wYWdlKzB4NTY4LzB4YmM0DQogWzw4MDM3YzFhOD5dIGtiZF9pbml0KzB4YzQvMHgx YzANCiBbPDgwMjM3YTU4Pl0gc2VyaWFsODI1MF9zdGFydF90eCsweDAvMHgyYw0KIFs8ODAyMWVh Y2M+XSB3cml0ZV9jaGFuKzB4NDA4LzB4NGE0DQogWzw4MDM3YzA0MD5dIHZjc19pbml0KzB4Nzgv MHhhMA0KIFs8ODAxNDEwODA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NDQNCiBb PDgwMTYxZjFjPl0gaGFuZGxlX21tX2ZhdWx0KzB4M2Q0LzB4NGYwDQogWzw4MDEyMGEwOD5dIF9f d2FrZV91cCsweDQwLzB4N2MNCiBbPDgwMjYzOTE4Pl0gc3lzX3NlbmR0bysweGMwLzB4ZjQNCiBb PDgwMjE1YWI4Pl0gdHR5X3dyaXRlKzB4MmIwLzB4NDQ0DQogWzw4MDIxNWI4MD5dIHR0eV93cml0 ZSsweDM3OC8weDQ0NA0KIFs8ODAxMDg1OWM+XSBkb19nZXR0aW1lb2ZkYXkrMHg3OC8weDE2MA0K IFs8ODAxMzY5YmM+XSBzeXNfcnRfc2lnYWN0aW9uKzB4ODQvMHhjYw0KIFs8ODAxMGI4ZTA+XSBz dGFja19kb25lKzB4MjAvMHgzYw0KIFs8ODAxMGI4ZTA+XSBzdGFja19kb25lKzB4MjAvMHgzYw0K DQoNCkNvZGU6IGFmYTMwMDI0ICAwMmM0ODAyMSAgOGU4NDAwMDAgPDhlMDMwMDU0PiA4YzgyMDA4 NCAgMDA0MzEwMjUgIGFjODIwMDg0ICA5MjA5MDA1MyAgMDAwOTEwYzINCjIuMTY4LjEuMSk6IDU2 IGRLZXJuZWwgcGFuaWMgLSBub3Qgc3luY2luZzogQWllZSwga2lsbGluZyBpbnRlcnJ1cHQgaGFu ZGxlciENCmF0YSBieXRlcw0KIDw2PndpZmkwOiBTVyBUSUNLIHN0dWNrPyBiaXRzPTB4MCBFdlN0 YXQ9ODAwMCBJbnRFbj1lMDlmDQo= --=-KD1/v3f9wG6oAY/fk5cb-- --=-xfbS5sb98PjtsvN8jDwx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJj3nRoMuWKCcbgQRAkJQAJ9kTMGrTxvD6K04XxoqqvN1j7QEpQCeLE1r YKEAgBgCjArV7AhC9gfI2cM= =aktd -----END PGP SIGNATURE----- --=-xfbS5sb98PjtsvN8jDwx-- From srinivas.vutukuri@gmail.com Thu Mar 3 10:37:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 10:37:46 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.207]:17210 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 10:37:30 +0000 Received: by wproxy.gmail.com with SMTP id 37so380370wra for ; Thu, 03 Mar 2005 02:37:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=sZxwz3zFfe9CWtjKdwvAbX4IB1X9pUrstvq9+J15l6lgApidQ/Z/ZiyhmbfZb8QXH29s9BUtld60uv0gJyl1uNyfDDOt3nD6sZ1yKNUHyTEuClbAtBGr4oJNWFaCpK0mRRN6FxDjEMG817Xv3sZLe69PXvETB3zr6TMWx4fm1A4= Received: by 10.54.65.4 with SMTP id n4mr22347wra; Thu, 03 Mar 2005 02:37:24 -0800 (PST) Received: by 10.54.25.31 with HTTP; Thu, 3 Mar 2005 02:37:22 -0800 (PST) Message-ID: Date: Thu, 3 Mar 2005 16:07:22 +0530 From: srinivas naga vutukuri Reply-To: srinivas naga vutukuri To: linux-mips@linux-mips.org Subject: HOWTO load and run the kernel image using redboot? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: srinivas.vutukuri@gmail.com Precedence: bulk X-list: linux-mips Hi, I have compiled the mips kernel image, and got vmlinux. And how can load image into the ram run using redboot, my board is running with the redboot. I followed the steps, after i got the vmlinux 1. mips-linux-objcopy -O binary -g vmlinux vmlinux.bin 2. gzip vmlinux.bin 3. mips-linux-objdump -f vmlinux | grep start shows the entry point, which is say ENTRY 4. mips-linux-nm vmlinux | grep _ftext which is say MEMADDR. 5. Load the image into memory At a RedBoot prompt, type: load -r -b %{FREEMEMLO} vmlinux.bin.gz 6. Copy the compressed image from memory to flash fis create -e ENTRY -r MEMADDR vmlinux.bin.gz and once i do go/exec, garbage is showing at the Redboot> prompt... Can help the way of loading the kernel image using redboot and boot it. Best Regards, srinivas. From ralf@linux-mips.org Thu Mar 3 11:15:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 11:15:19 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:53256 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 11:15:04 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j23BElM6009004 for ; Thu, 3 Mar 2005 11:14:47 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j23AmkKT007386; Thu, 3 Mar 2005 10:48:46 GMT Date: Thu, 3 Mar 2005 10:48:46 +0000 From: Ralf Baechle To: Prasad Venkata Boddupalli Cc: linux-mips@linux-mips.org Subject: Re: cross-compile toolchain for linux-mips64? Message-ID: <20050303104846.GC5457@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 27, 2005 at 05:28:57PM -0700, Prasad Venkata Boddupalli wrote: > Is 'egcs-mips64-linux-1.1.2-2.i386.rpm' the latest binary of > 'cross-compile toolchain' for linux-mips64 targets or do we have a later > version ? Also, can someone point to a URL I can download it from? It seems you have tried to look at {ftp,www}.linux-mips.org or your favorite search engine ... Ralf From ralf@linux-mips.org Thu Mar 3 11:18:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 11:18:32 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:6161 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 11:18:17 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j23BElM8009004; Thu, 3 Mar 2005 11:14:48 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j23Akti3007358; Thu, 3 Mar 2005 10:46:55 GMT Date: Thu, 3 Mar 2005 10:46:54 +0000 From: Ralf Baechle To: Jeroen Vreeken Cc: Geert Uytterhoeven , Linux/MIPS Development Subject: Re: sparse and mips Message-ID: <20050303104654.GB5457@linux-mips.org> References: <422256A3.2030407@amsat.org> <20050228121120.GA11719@linux-mips.org> <4223240C.4010207@amsat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4223240C.4010207@amsat.org> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 28, 2005 at 03:00:44PM +0100, Jeroen Vreeken wrote: > Adding the following few lines fixes the problems with the headers (they > are normally defined by gcc)... > I am not sure that is all that is needed (the rest might just be me > doing bad things in my driver) but since they are mips specific I think > arch/mips/Makefile would be the right place for them: > > CHECKFLAGS += -D__mips__ > ifdef CONFIG_MIPS32 > CHECKFLAGS += -D_MIPS_SZLONG=32 I went for something slightly more beautyful: CHECKFLAGS-y += -D__linux__ -D__mips__ CHECKFLAGS-$(CONFIG_MIPS32) += -D_MIPS_SZLONG=32 \ -D__PTRDIFF_TYPE__=int CHECKFLAGS-$(CONFIG_MIPS64) += -D_MIPS_SZLONG=64 \ -D__PTRDIFF_TYPE__="long int" CHECKFLAGS-$(CONFIG_CPU_BIG_ENDIAN) += -D__MIPSEL__ CHECKFLAGS-$(CONFIG_CPU_LITTLE_ENDIAN) += -D__MIPSEL__ Still needs a few more symbols I guess. And I fixed a few of the worst offenders, especially uaccess.h. Ralf From eckhardt@satorlaser.com Thu Mar 3 11:35:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 11:35:49 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.186]:43233 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 11:35:34 +0000 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1D6oc90jYK-0006vz; Thu, 03 Mar 2005 12:35:33 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: sparse and mips Date: Thu, 3 Mar 2005 12:38:38 +0100 User-Agent: KMail/1.7.1 References: <422256A3.2030407@amsat.org> <4223240C.4010207@amsat.org> <20050303104654.GB5457@linux-mips.org> In-Reply-To: <20050303104654.GB5457@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503031238.38363.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > CHECKFLAGS-$(CONFIG_CPU_BIG_ENDIAN) += -D__MIPSEL__ > CHECKFLAGS-$(CONFIG_CPU_LITTLE_ENDIAN) += -D__MIPSEL__ typo? ;) Uli From ralf@linux-mips.org Thu Mar 3 11:50:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 11:50:52 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:38922 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 11:50:37 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j23BoKDP011397; Thu, 3 Mar 2005 11:50:20 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j23BoKDG011396; Thu, 3 Mar 2005 11:50:20 GMT Date: Thu, 3 Mar 2005 11:50:20 +0000 From: Ralf Baechle To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org Subject: Re: sparse and mips Message-ID: <20050303115020.GB10556@linux-mips.org> References: <422256A3.2030407@amsat.org> <4223240C.4010207@amsat.org> <20050303104654.GB5457@linux-mips.org> <200503031238.38363.eckhardt@satorlaser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503031238.38363.eckhardt@satorlaser.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Mar 03, 2005 at 12:38:38PM +0100, Ulrich Eckhardt wrote: > Ralf Baechle wrote: > > CHECKFLAGS-$(CONFIG_CPU_BIG_ENDIAN) += -D__MIPSEL__ > > CHECKFLAGS-$(CONFIG_CPU_LITTLE_ENDIAN) += -D__MIPSEL__ > > typo? ;) Guess I've been assimilated ;) Ralf From Christophe.Jelger@unibas.ch Thu Mar 3 14:55:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 14:56:02 +0000 (GMT) Received: from balu1.urz.unibas.ch ([IPv6:::ffff:131.152.1.51]:50133 "EHLO balu1.urz.unibas.ch") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 14:55:46 +0000 Received: from [192.168.1.102] (banana.cs.unibas.ch [131.152.55.9]) by balu1.urz.unibas.ch (8.12.10/8.12.10) with ESMTP id j23EtiTL012084 for ; Thu, 3 Mar 2005 15:55:44 +0100 Message-ID: <42272589.7000802@unibas.ch> Date: Thu, 03 Mar 2005 15:56:09 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Newbie : Cross-compiling module for wrt54g Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Christophe.Jelger@unibas.ch Precedence: bulk X-list: linux-mips Hi everybody, Well I am a complete newbie to using MIPS devices and I would like to cross-compile an extra linux module for the Linksys wrt54g wireless router. The module is not a standard linux module, it is an underlay routing protocol (LUNAR) for wireless ad hoc networks. I checked on the web, but I'm not sure on how I should proceed as many information I found seem outdated. If somebody could help me to get on tracks, I'd of course appreciate. The issues I have are : tools to use, kernel-header files versions (wrt54g uses 2.4.20, means do I have to compile on a 2.4.20 machine ?), debugging on wrt54g (can I use standard log-file ?). Looking forward to some help. regards Christophe From jaypee@hotpop.com Thu Mar 3 16:29:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 16:29:30 +0000 (GMT) Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:36534 "EHLO smtp-out.hotpop.com") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 16:29:13 +0000 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 80085F4F148 for ; Thu, 3 Mar 2005 16:29:03 +0000 (UTC) Received: from [192.168.0.85] (unknown [83.104.11.251]) by smtp-2.hotpop.com (Postfix) with ESMTP id C253CF4F0E4; Thu, 3 Mar 2005 16:29:01 +0000 (UTC) Subject: Re: Newbie : Cross-compiling module for wrt54g From: JP To: Christophe Jelger Cc: linux-mips@linux-mips.org In-Reply-To: <42272589.7000802@unibas.ch> References: <42272589.7000802@unibas.ch> Content-Type: text/plain Date: Thu, 03 Mar 2005 16:29:04 +0000 Message-Id: <1109867344.9625.74.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jaypee@hotpop.com Precedence: bulk X-list: linux-mips Christophe > The issues I have are : tools to use, kernel-header files versions > (wrt54g uses 2.4.20, means do I have to compile on a 2.4.20 machine ?), > debugging on wrt54g (can I use standard log-file ?). You'll need the header files that linksys used which may or may not be different to the 2.4.10 vanilla kernel headers for the wrt54g you can get the right code for your FW rev here. http://www.linksys.com/support/gpl.asp Here's a page about tools http://www.linux-mips.org/wiki/index.php/Toolchains You might need an older toolchain to build 2.4 kernels. Anyone have any success on build 2.4.x with gcc 3.x? Don't take my word for it though I've been using a recentish gcc-3.4.1 built using uclibc's buildroot to build It was pretty easy to get working and install. For our 2.4 kernels I used a montavista toolchain for the last few years. mvista.com requires you register. Happy hacking -- JP From wbx@openbsd-geek.de Thu Mar 3 23:25:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Mar 2005 23:25:58 +0000 (GMT) Received: from chrom.openbsd-geek.de ([IPv6:::ffff:217.160.135.112]:51031 "EHLO chrom.openbsd-geek.de") by linux-mips.org with ESMTP id ; Thu, 3 Mar 2005 23:25:43 +0000 Received: by chrom.openbsd-geek.de (Postfix, from userid 1000) id 63B9732555; Fri, 4 Mar 2005 00:25:41 +0100 (CET) Date: Fri, 4 Mar 2005 00:25:41 +0100 From: Waldemar Brodkorb To: Christophe Jelger Cc: linux-mips@linux-mips.org Subject: Re: Newbie : Cross-compiling module for wrt54g Message-ID: <20050303232540.GA12906@openbsd-geek.de> References: <42272589.7000802@unibas.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42272589.7000802@unibas.ch> X-Editor: VIM X-Operating-System: OpenBSD 3.6 i386 User-Agent: Mutt/1.5.6i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wbx@openbsd-geek.de Precedence: bulk X-list: linux-mips Hi, Christophe Jelger wrote, > Hi everybody, > > Well I am a complete newbie to using MIPS devices and I would like to > cross-compile an extra linux module for the Linksys wrt54g wireless > router. The module is not a standard linux module, it is an underlay > routing protocol (LUNAR) for wireless ad hoc networks. > > I checked on the web, but I'm not sure on how I should proceed as many > information I found seem outdated. > > If somebody could help me to get on tracks, I'd of course appreciate. > The issues I have are : tools to use, kernel-header files versions > (wrt54g uses 2.4.20, means do I have to compile on a 2.4.20 machine ?), > debugging on wrt54g (can I use standard log-file ?). > > Looking forward to some help. You could try www.openwrt.org. There is even an experimental version, which uses a kernel 2.4.29. bye Waldemar From p2@mind.be Fri Mar 4 00:05:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 00:05:35 +0000 (GMT) Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:21632 "EHLO nat.office.mind.be") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 00:05:19 +0000 Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian)) id 1D70Jh-00010l-00; Fri, 04 Mar 2005 01:05:17 +0100 Date: Fri, 4 Mar 2005 01:05:16 +0100 To: linux-mips@linux-mips.org, ths@debian.org Subject: G450 in 2.6 on swarm Message-ID: <20050304000516.GA3539@mind.be> Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org, ths@debian.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline X-Answer: 42 X-Operating-system: Debian GNU/Linux X-Message-Flag: Get yourself a real email client. http://www.mutt.org/ X-mate: Mate, man gewoehnt sich an alles User-Agent: Mutt/1.5.6+20040907i From: Peter 'p2' De Schrijver Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: p2@mind.be Precedence: bulk X-list: linux-mips --mxv5cy4qt+RJ9ypb Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The attached patch makes the matrox G450 work on the swarm board in 32bit 2= =2E6 kernels. The patch has only been verified on big endian swarm systems.=20 Enjoy, Peter (p2). --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch1 Content-Transfer-Encoding: quoted-printable diff -ur -x Entries linux/drivers/video/matrox/matroxfb_base.h linux.my/dri= vers/video/matrox/matroxfb_base.h --- linux/drivers/video/matrox/matroxfb_base.h 2005-02-07 03:54:54.00000000= 0 +0100 +++ linux.my/drivers/video/matrox/matroxfb_base.h 2005-03-01 01:35:18.00000= 0000 +0100 @@ -136,23 +136,23 @@ } vaddr_t; =20 static inline unsigned int mga_readb(vaddr_t va, unsigned int offs) { - return readb(va.vaddr + offs); + return fb_readb(va.vaddr + offs); } =20 static inline void mga_writeb(vaddr_t va, unsigned int offs, u_int8_t valu= e) { - writeb(value, va.vaddr + offs); + fb_writeb(value, va.vaddr + offs); } =20 static inline void mga_writew(vaddr_t va, unsigned int offs, u_int16_t val= ue) { - writew(value, va.vaddr + offs); + fb_writew(value, va.vaddr + offs); } =20 static inline u_int32_t mga_readl(vaddr_t va, unsigned int offs) { - return readl(va.vaddr + offs); + return fb_readl(va.vaddr + offs); } =20 static inline void mga_writel(vaddr_t va, unsigned int offs, u_int32_t val= ue) { - writel(value, va.vaddr + offs); + fb_writel(value, va.vaddr + offs); } =20 static inline void mga_memcpy_toio(vaddr_t va, const void* src, int len) { @@ -170,14 +170,14 @@ =20 if ((unsigned long)src & 3) { while (len >=3D 4) { - writel(get_unaligned((u32 *)src), addr); + fb_writel(get_unaligned((u32 *)src), addr); addr++; len -=3D 4; src +=3D 4; } } else { while (len >=3D 4) { - writel(*(u32 *)src, addr); + fb_writel(*(u32 *)src, addr); addr++; len -=3D 4; src +=3D 4; @@ -715,9 +715,10 @@ =20 #define M_C2CTL 0x3C10 =20 -#define MX_OPTION_BSWAP 0x00000000 =20 #ifdef __LITTLE_ENDIAN +#define MX_OPTION_BSWAP 0x00000000 + #define M_OPMODE_4BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_BL= IT) #define M_OPMODE_8BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_BL= IT) #define M_OPMODE_16BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_B= LIT) @@ -725,11 +726,13 @@ #define M_OPMODE_32BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_B= LIT) #else #ifdef __BIG_ENDIAN +#define MX_OPTION_BSWAP 0x80000000 + #define M_OPMODE_4BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_= DMA_BLIT) /* TODO */ -#define M_OPMODE_8BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_BE_8BPP | M_OPMODE_= DMA_BLIT) -#define M_OPMODE_16BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_BE_16BPP | M_OPMODE= _DMA_BLIT) -#define M_OPMODE_24BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_BE_8BPP | M_OPMODE= _DMA_BLIT) /* TODO, ?32 */ -#define M_OPMODE_32BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_BE_32BPP | M_OPMODE= _DMA_BLIT) +#define M_OPMODE_8BPP (M_OPMODE_DMA_BE_8BPP | M_OPMODE_DIR_BE_8BPP | M_OP= MODE_DMA_BLIT) +#define M_OPMODE_16BPP (M_OPMODE_DMA_BE_16BPP | M_OPMODE_DIR_BE_16BPP | M_= OPMODE_DMA_BLIT) +#define M_OPMODE_24BPP (M_OPMODE_DMA_BE_8BPP | M_OPMODE_DIR_BE_8BPP | M_O= PMODE_DMA_BLIT) /* TODO, ?32 */ +#define M_OPMODE_32BPP (M_OPMODE_DMA_BE_32BPP | M_OPMODE_DIR_BE_32BPP | M_= OPMODE_DMA_BLIT) #else #error "Byte ordering have to be defined. Cannot continue." #endif @@ -741,7 +744,12 @@ #define mga_outw(addr,val) mga_writew(ACCESS_FBINFO(mmio.vbase), (addr), (= val)) #define mga_outl(addr,val) mga_writel(ACCESS_FBINFO(mmio.vbase), (addr), (= val)) #define mga_readr(port,idx) (mga_outb((port),(idx)), mga_inb((port)+1)) +#ifdef __LITTLE_ENDIAN #define mga_setr(addr,port,val) mga_outw(addr, ((val)<<8) | (port)) +#else +#define mga_setr(addr,port,val) do { mga_outb(addr, port); mga_outb((addr)= +1, val); } while (0) +#endif + =20 #define mga_fifo(n) do {} while ((mga_inl(M_FIFOSTATUS) & 0xFF) < (n)) =20 --wRRV7LY7NUeQGEoC-- --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCJ6Y8KLKVw/RurbsRAgXkAJ0R65VJhQqqFFcSTC/8awvsDW7JbQCbBXri WJXhEq7Z0OE1kdj3MOd4WoY= =bY3Q -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From anemo@mba.ocn.ne.jp Fri Mar 4 10:43:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 10:44:04 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:7707 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Fri, 4 Mar 2005 10:43:47 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 4 Mar 2005 10:43:46 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 09FFD1F31C; Fri, 4 Mar 2005 19:43:42 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id EA4E61F31A; Fri, 4 Mar 2005 19:43:41 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j24Ahf9c096235; Fri, 4 Mar 2005 19:43:41 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 04 Mar 2005 19:43:41 +0900 (JST) Message-Id: <20050304.194341.01917677.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: 2.6.11 preemption fix From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips It seems 2.6.11 preemption kernel is broken. The preempt_schedule_irq() expects preempt_count is 0. Also trailing branch instructino have been lost. How about this fix? --- linux-mips/arch/mips/kernel/entry.S 2005-02-10 11:27:50.000000000 +0900 +++ linux/arch/mips/kernel/entry.S 2005-03-04 17:09:53.000000000 +0900 @@ -58,9 +58,8 @@ LONG_L t0, PT_STATUS(sp) # Interrupts off? andi t0, 1 beqz t0, restore_all - li t0, PREEMPT_ACTIVE - sw t0, TI_PRE_COUNT($28) jal preempt_schedule_irq + b need_resched #endif FEXPORT(ret_from_fork) --- Atsushi Nemoto From ralf@linux-mips.org Fri Mar 4 12:36:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 12:36:51 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:64784 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 12:36:36 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j24CaBMc008106; Fri, 4 Mar 2005 12:36:11 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j24CaAuK008105; Fri, 4 Mar 2005 12:36:10 GMT Date: Fri, 4 Mar 2005 12:36:09 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: 2.6.11 preemption fix Message-ID: <20050304123609.GC7073@linux-mips.org> References: <20050304.194341.01917677.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304.194341.01917677.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Mar 04, 2005 at 07:43:41PM +0900, Atsushi Nemoto wrote: > It seems 2.6.11 preemption kernel is broken. > > The preempt_schedule_irq() expects preempt_count is 0. Also trailing > branch instructino have been lost. How about this fix? Looking good. Applied, Ralf From ralf@linux-mips.org Fri Mar 4 14:39:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 14:39:26 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:35855 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 14:39:11 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j24EcDFL011272; Fri, 4 Mar 2005 14:38:13 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j24Ec8tL011260; Fri, 4 Mar 2005 14:38:08 GMT Date: Fri, 4 Mar 2005 14:38:08 +0000 From: Ralf Baechle To: Peter Horton Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] Cobalt 1/2: tidy up PCI fixups Message-ID: <20050304143808.GA10224@linux-mips.org> References: <20050301083852.GA2017@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301083852.GA2017@skeleton-jack> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Mar 01, 2005 at 08:38:52AM +0000, Peter Horton wrote: > It's not necessary to hide Galileo if we correctly mark it as a host > bridge. Indeed, that's the right thing to do and it should be done on a bunch of other systems also. Ralf From ralf@linux-mips.org Fri Mar 4 15:14:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 15:14:15 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:12563 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 15:14:01 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j24FD53X012320; Fri, 4 Mar 2005 15:13:06 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j24FD5Ee012319; Fri, 4 Mar 2005 15:13:05 GMT Date: Fri, 4 Mar 2005 15:13:05 +0000 From: Ralf Baechle To: Peter Horton Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] Cobalt 2/2: add support for Qube2700 Message-ID: <20050304151305.GA12169@linux-mips.org> References: <20050301084138.GB2017@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301084138.GB2017@skeleton-jack> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Mar 01, 2005 at 08:41:38AM +0000, Peter Horton wrote: > On Qube2700 Galileo hangs if we access slot #6. Patch is ok. Out of curiosity, is the reason known? Ralf From Christophe.Jelger@unibas.ch Fri Mar 4 16:48:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 16:48:40 +0000 (GMT) Received: from balu1.urz.unibas.ch ([IPv6:::ffff:131.152.1.51]:40682 "EHLO balu1.urz.unibas.ch") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 16:48:24 +0000 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.12.10/8.12.10) with ESMTP id j24GmMTL025605 for ; Fri, 4 Mar 2005 17:48:22 +0100 Message-ID: <4228916F.9070600@unibas.ch> Date: Fri, 04 Mar 2005 17:48:47 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Newbie : Cross-compiling module for wrt54g References: <42272589.7000802@unibas.ch> <1109867344.9625.74.camel@localhost.localdomain> In-Reply-To: <1109867344.9625.74.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Christophe.Jelger@unibas.ch Precedence: bulk X-list: linux-mips Thanks to people who replied ... I will spend some time trying to build the module and see what happens ! JP, I don't know if you meant compiling a standard (or a mips ?) 2.4 kernel with gcc 3.4.1, but I know it works with gcc 3.3.5 for the standard kernel. Regards Christophe JP wrote: > (...) > > You might need an older toolchain to build 2.4 kernels. > Anyone have any success on build 2.4.x with gcc 3.x? > > Don't take my word for it though I've been using a recentish gcc-3.4.1 > built using uclibc's buildroot to build > It was pretty easy to get working and install. > > For our 2.4 kernels I used a montavista toolchain for the last few > years. mvista.com requires you register. > > Happy hacking > From ralf@linux-mips.org Fri Mar 4 17:13:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 17:13:35 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:61725 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 17:13:20 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j24HCsuP025890; Fri, 4 Mar 2005 17:12:54 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j24HCrZV025878; Fri, 4 Mar 2005 17:12:53 GMT Date: Fri, 4 Mar 2005 17:12:53 +0000 From: Ralf Baechle To: Christophe Jelger Cc: linux-mips@linux-mips.org Subject: Re: Newbie : Cross-compiling module for wrt54g Message-ID: <20050304171253.GB12169@linux-mips.org> References: <42272589.7000802@unibas.ch> <1109867344.9625.74.camel@localhost.localdomain> <4228916F.9070600@unibas.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4228916F.9070600@unibas.ch> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Mar 04, 2005 at 05:48:47PM +0100, Christophe Jelger wrote: > Thanks to people who replied ... I will spend some time trying to build > the module and see what happens ! > > JP, I don't know if you meant compiling a standard (or a mips ?) 2.4 > kernel with gcc 3.4.1, but I know it works with gcc 3.3.5 for the > standard kernel. Compiling 2.4 with gcc 3.4 will fail for certain configurations. Even where it successfully builds there is always the danger that a more modern that is aggressive optimizer will do unexpected things to code - and OS code is very fragile in that aspect. Thus I recommend to use only 2.95.3 ... 3.3 for Linux 2.4. For 2.6 anything between 2.95.3 ... 4.0 has been tested - but 4.0 is still a bit on the daring side while 3.4 has been tested well on many platforms. Of course you may always be lucky - or have too much time on your hands ;-) Ralf From ralf@linux-mips.org Fri Mar 4 20:24:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 20:24:38 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:60176 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 20:24:20 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j24KNd1R014299; Fri, 4 Mar 2005 20:23:39 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j24KNcQn014298; Fri, 4 Mar 2005 20:23:38 GMT Date: Fri, 4 Mar 2005 20:23:38 +0000 From: Ralf Baechle To: Dan Malek Cc: JP Foster , linux-mips@linux-mips.org Subject: Re: Big Endian au1550 Message-ID: <20050304202338.GA14128@linux-mips.org> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> <20050223150617.GA18290@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 23, 2005 at 12:02:47PM -0500, Dan Malek wrote: > >So I guess this would apply to all Alchemy-based platforms and thus I > >should offer big endian on all of them again? > > Yes, big endian should be an option. If it doesn't work, it > should get fixed :-) Okay. I don't know which of the Alchemy systems are capable of supporting big endian at all - some might not due to unavailable firmware for example. So I guess I'll leave cooking a patch to you or Pete. Ralf From dan@embeddededge.com Fri Mar 4 20:44:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Mar 2005 20:44:49 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:60167 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Fri, 4 Mar 2005 20:44:34 +0000 Received: from [10.1.100.57] ([64.164.196.27]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j24KiZX5028537; Fri, 4 Mar 2005 15:44:35 -0500 In-Reply-To: <20050304202338.GA14128@linux-mips.org> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> <20050223150617.GA18290@linux-mips.org> <20050304202338.GA14128@linux-mips.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7f99ffacb17cd1e961c026057fb89571@embeddededge.com> Content-Transfer-Encoding: 7bit Cc: JP Foster , linux-mips@linux-mips.org From: Dan Malek Subject: Re: Big Endian au1550 Date: Fri, 4 Mar 2005 12:44:26 -0800 To: Ralf Baechle Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@embeddededge.com Precedence: bulk X-list: linux-mips On Mar 4, 2005, at 12:23 PM, Ralf Baechle wrote: > Okay. I don't know which of the Alchemy systems are capable of > supporting > big endian at all - They all will. > some might not due to unavailable firmware for example. Well, you can (and I have) changed the mode when booting the kernel from what the boot rom initialized. It's not pretty, but it works. > So I guess I'll leave cooking a patch to you or Pete. OK. -- Dan From goldfinger@member.fsf.org Sat Mar 5 12:28:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Mar 2005 12:28:44 +0000 (GMT) Received: from host238-156.pool80180.interbusiness.it ([IPv6:::ffff:80.180.156.238]:39666 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Sat, 5 Mar 2005 12:28:28 +0000 Received: by localhost.localdomain (Postfix, from userid 501) id 543F7110DF5; Sat, 5 Mar 2005 14:28:01 +0100 (CET) Subject: still ip27 problems From: Michele Carla` To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 05 Mar 2005 14:28:00 +0100 Message-Id: <1110029280.3448.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: goldfinger@member.fsf.org Precedence: bulk X-list: linux-mips Hi, I'm still trying to run linux on an ip27... the only kernel that I can boot succesfully (via network) is the iluxa's one: http://www.selfsoft.com/progs/mips/kernels/vmlinux.ip27-20040428 (except for networking, it has some problem with the IOC3 network interface) all other precompiled image (I have found... if you have others, please tell me) fails. I'm trying to compile another one. is there a "suggested" version (of the kernel and compiler) ? should I abilitate the Dallas 1-wire, or the IOC3 driver has an hardcoded support for this ? Thanks Michele Carla` goldfinger@member.fsf.org From pchapman@spartan.ac.BrockU.CA Sat Mar 5 15:02:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Mar 2005 15:02:51 +0000 (GMT) Received: from spartan.ac.BrockU.CA ([IPv6:::ffff:139.57.65.3]:15790 "EHLO spartan.ac.BrockU.CA") by linux-mips.org with ESMTP id ; Sat, 5 Mar 2005 15:02:34 +0000 Received: from spartan.ac.BrockU.CA (localhost.localdomain [127.0.0.1]) by spartan.ac.BrockU.CA (8.12.8/8.12.8) with ESMTP id j25F2Rgc030213 for ; Sat, 5 Mar 2005 10:02:27 -0500 Received: (from pchapman@localhost) by spartan.ac.BrockU.CA (8.12.8/8.12.8/Submit) id j25F2RAp030211 for linux-mips@linux-mips.org; Sat, 5 Mar 2005 10:02:27 -0500 Date: Sat, 5 Mar 2005 10:02:27 -0500 From: Paul Chapman To: linux-mips@linux-mips.org Subject: Re: still ip27 problems Message-ID: <20050305150227.GA27220@spartan.ac.BrockU.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pchapman@spartan.ac.BrockU.CA Precedence: bulk X-list: linux-mips Hello, I've got an IP27 up and running with 2.6.11 from CVS, and it seems pretty robust. I cross-compiled from x86 with the handy-dandy RPMS kindly provided by Maciej (see "Toolchains" in the wiki). I used: binutils-mips64-linux-2.15-1 gcc-mips64-linux-3.4.3-1 The ip27 defconfigs produce a workable system. Previous 2.6.11-rc* CVS versions were broken on ip27. HOWEVER, I have only been able to get my Origin 200 to work with one node. If I hook up the other node, I get lots of woe (woe enclosed below). If you're using more than one node, I suggest unhooking the others to start off with.. If you can't xcompile, I can send you my vmlinux + modules.. -Paul Chapman Linux version 2.6.11 (pchapman@paul.dev.brocku.ca) (gcc version 3.4.3) #11 SMP Thu Mar 3 09:11:55 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Discovered 4 cpus on 2 nodes node_distance: router_a NULL node_distance: router_a NULL node_distance: router_a NULL node_distance: router_a NULL ************** Topology ******************** 00 01 00 255 255 01 255 255 CPU revision is: 00000e35 FPU revision is: 00000900 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has a secondary CPU, CPU is running. Machine is in M mode. CPU 0 clock is 360MHz. Cpu 0, Nasid 0x0: partnum 0xc002 is a bridge Determined physical RAM map: Built 2 zonelists Kernel command line: root=/dev/sdc1 root=/dev/sdc1 Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. Unified secondary cache 4096kB 2-way, linesize 128 bytes. Synthesized TLB refill handler (41 instructions). Synthesized TLB load handler fastpath (55 instructions). Synthesized TLB store handler fastpath (55 instructions). Synthesized TLB modify handler fastpath (54 instructions). PID hash table entries: 4096 (order: 12, 131072 bytes) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Memory: 502592k/524288k available (2781k kernel code, 21696k reserved, 1056k data, 224k init, 0k) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) Checking for 'wait' instruction... unavailable. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. per-CPU timeslice cutoff: 11989235.47 usecs. task migration cache decay timeout: 11961 msecs. REPLICATION: ON nasid 0, ktext from nasid 0, kdata from nasid 0 REPLICATION: ON nasid 1, ktext from nasid 0, kdata from nasid 0 CPU revision is: 00000e35 FPU revision is: 00000900 Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. Unified secondary cache 4096kB 2-way, linesize 128 bytes. Synthesized TLB refill handler (41 instructions). CPU 1 clock is 360MHz. CPU revision is: 00000e35 FPU revision is: 00000900 Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. Unified secondary cache 4096kB 2-way, linesize 128 bytes. Badness in smp_call_function at arch/mips/kernel/smp.c:167 Call Trace: [] smp_call_function+0x1f0/0x1f8 [] printk+0x2c/0x38 [] local_r4k___flush_cache_all+0x0/0xc8 [] r4k___flush_cache_all+0x38/0x50 [] ld_mmu_r4xx0+0xab4/0x13f0 [] per_cpu_trap_init+0x158/0x180 [] start_secondary+0x24/0xd0 Badness in smp_call_function at arch/mips/kernel/smp.c:167 Call Trace: [] smp_call_function+0x1f0/0x1f8 [] local_r4k_flush_icache_range+0x0/0x148 [] r4k_flush_icache_range+0x40/0x58 [] dump_stack+0x14/0x20 [] build_clear_page+0x10f4/0x1220 [] ld_mmu_r4xx0+0xb20/0x13f0 [] per_cpu_trap_init+0x158/0x180 [] start_secondary+0x24/0xd0 Badness in smp_call_function at arch/mips/kernel/smp.c:167 Call Trace: [] smp_call_function+0x1f0/0x1f8 [] local_r4k_flush_icache_range+0x0/0x148 [] dump_stack+0x14/0x20 [] local_r4k_flush_icache_range+0x0/0x148 [] r4k_flush_icache_range+0x40/0x58 [] build_copy_page+0x1bcc/0x1fe0 [] dump_stack+0x14/0x20 [] per_cpu_trap_init+0x158/0x180 [] start_secondary+0x24/0xd0 Synthesized TLB refill handler (41 instructions). Badness in smp_call_function at arch/mips/kernel/smp.c:167 Call Trace: [] smp_call_function+0x1f0/0x1f8 [] local_r4k_flush_icache_range+0x0/0x148 [] r4k_flush_icache_range+0x40/0x58 [] build_tlb_refill_handler+0x3d8/0x1548 [] build_copy_page+0x1bcc/0x1fe0 [] dump_stack+0x14/0x20 [] start_secondary+0x24/0xd0 CPU 2 clock is 360MHz. Cpu 2, Nasid 0x1: partnum 0xc002 is a bridge Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]: Cpu 0 $ 0 : 0000000000000000 0000000000420000 0000000000010000 0000000000010100 $ 4 : 0000000000000000 0000000000000000 0000000000000001 000000000000003f $ 8 : 00000000fffb6d8e a80000011bff0c80 0000000000000000 0000000000008000 $12 : 0000000000000400 000000001000001f 0000000000000000 9600000100002400 $16 : 0000000000000000 9200000001000000 9200000001000098 0000000000000000 $20 : a8000001009f7c90 a80000000042d080 0000000000000000 000000000000000a $24 : 0000000000000000 ffffffffbfc00038 $28 : a8000001009f4000 a8000001009f7c50 0000000000000000 a80000000002a53c Hi : 0000000000000000 Lo : 0000000000000000 epc : 0000000000000000 0x0 Not tainted ra : a80000000002a53c smp_call_function_interrupt+0x74/0xc8 Status: 94001ce2 KX SX UX KERNEL EXL Cause : 0000c008 BadVA : 0000000000000000 PrId : 00000e35 Modules linked in: Process swapper (pid: 1, threadinfo=a8000001009f4000, task=a80000001bfa57f8) Stack : 0000000000000200 a80000000001d8c0 0000000000000400 0000000000000002 0000000000000002 0000000000000002 a800000000422c78 a800000000021630 0000000000000000 ffffffff94201ce1 a80000000042d080 0000000000000000 0000000000000002 a800000100652520 0000000000000001 000000000000003f 00000000fffb6d8e a80000011bff0c80 0000000000000000 0000000000008000 0000000000001000 000000001000001f 0000000000000000 9600000100002400 0000000000000002 0000000000000002 0000000000000002 0000000000000002 a800000000422c78 a80000000042d080 0000000000000000 000000000000000a 0000000000000000 ffffffffbfc00038 0000000000000000 0000000000000000 a8000001009f4000 a8000001009f7dc0 0000000000000000 a800000000061ea0 ... Call Trace: [] ip27_do_irq_mask0+0x190/0x198 [] ret_from_irq+0x0/0x10 [] do_softirq+0x98/0xb8 [] __do_softirq+0x8c/0x238 [] do_softirq+0x98/0xb8 [] ret_from_irq+0x0/0x10 [] __cpu_up+0x3c/0x188 [] __cpu_up+0xe4/0x188 [] cpu_up+0x19c/0x2b0 [] cpu_up+0x188/0x2b0 [] init+0x9f8/0xac0 [] kernel_thread_helper+0x10/0x18 [] kernel_thread_helper+0x0/0x18 Code: (Bad address in epc) Kernel panic - not syncing: Aiee, killing interrupt handler! From domen@coderock.org Sun Mar 6 10:45:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:46:14 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:13227 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:45:55 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id A18D81F23E; Sun, 6 Mar 2005 11:45:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 9E7641F203; Sun, 6 Mar 2005 11:45:50 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 56C701F1F0; Sun, 6 Mar 2005 11:45:48 +0100 (CET) Subject: [patch 1/8] delete unused file arch_mips_arc_salone.c To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:45:48 +0100 Message-Id: <20050306104548.56C701F1F0@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/arch/mips/arc/salone.c | 24 ------------------------ 1 files changed, 24 deletions(-) diff -L arch/mips/arc/salone.c -puN arch/mips/arc/salone.c~remove_file-arch_mips_arc_salone.c /dev/null --- kj/arch/mips/arc/salone.c +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,24 +0,0 @@ -/* - * Routines to load into memory and execute stand-along program images using - * ARCS PROM firmware. - * - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - */ -#include -#include - -LONG __init ArcLoad(CHAR *Path, ULONG TopAddr, ULONG *ExecAddr, ULONG *LowAddr) -{ - return ARC_CALL4(load, Path, TopAddr, ExecAddr, LowAddr); -} - -LONG __init ArcInvoke(ULONG ExecAddr, ULONG StackAddr, ULONG Argc, CHAR *Argv[], - CHAR *Envp[]) -{ - return ARC_CALL5(invoke, ExecAddr, StackAddr, Argc, Argv, Envp); -} - -LONG __init ArcExecute(CHAR *Path, LONG Argc, CHAR *Argv[], CHAR *Envp[]) -{ - return ARC_CALL4(exec, Path, Argc, Argv, Envp); -} _ From domen@coderock.org Sun Mar 6 10:46:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:46:58 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:14763 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:00 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id 019C81F23F; Sun, 6 Mar 2005 11:45:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 79B191F23D; Sun, 6 Mar 2005 11:45:57 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 3FDD91F204; Sun, 6 Mar 2005 11:45:51 +0100 (CET) Subject: [patch 2/8] delete unused file arch_mips_pmc_sierra_yosemite_ht_irq.c To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:45:50 +0100 Message-Id: <20050306104551.3FDD91F204@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/arch/mips/pmc-sierra/yosemite/ht-irq.c | 53 ------------------------------ 1 files changed, 53 deletions(-) diff -L arch/mips/pmc-sierra/yosemite/ht-irq.c -puN arch/mips/pmc-sierra/yosemite/ht-irq.c~remove_file-arch_mips_pmc_sierra_yosemite_ht_irq.c /dev/null --- kj/arch/mips/pmc-sierra/yosemite/ht-irq.c +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,53 +0,0 @@ -/* - * Copyright 2003 PMC-Sierra - * Author: Manish Lachwani (lachwani@pmc-sierra.com) - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#include -#include -#include -#include -#include -#include - -/* - * HT Bus fixup for the Titan - * XXX IRQ values need to change based on the board layout - */ -void __init titan_ht_pcibios_fixup_bus(struct pci_bus *bus) -{ - struct pci_bus *current_bus = bus; - struct pci_dev *devices; - struct list_head *devices_link; - - list_for_each(devices_link, &(current_bus->devices)) { - devices = pci_dev_b(devices_link); - if (devices == NULL) - continue; - } - - /* - * PLX and SPKT related changes go here - */ - -} _ From domen@coderock.org Sun Mar 6 10:47:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:47:43 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:15787 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:04 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id DAED01F23F; Sun, 6 Mar 2005 11:46:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id D00A11F23D; Sun, 6 Mar 2005 11:46:01 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 4D2161F1F0; Sun, 6 Mar 2005 11:45:54 +0100 (CET) Subject: [patch 3/8] delete unused file include_asm_mips_gfx.h To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:45:53 +0100 Message-Id: <20050306104554.4D2161F1F0@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/include/asm-mips/gfx.h | 55 ---------------------------------------------- 1 files changed, 55 deletions(-) diff -L include/asm-mips/gfx.h -puN include/asm-mips/gfx.h~remove_file-include_asm_mips_gfx.h /dev/null --- kj/include/asm-mips/gfx.h +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,55 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * This is the user-visible SGI GFX interface. - * - * This must be used verbatim into the GNU libc. It does not include - * any kernel-only bits on it. - * - * miguel@nuclecu.unam.mx - */ -#ifndef _ASM_GFX_H -#define _ASM_GFX_H - -/* The iocls, yes, they do not make sense, but such is life */ -#define GFX_BASE 100 -#define GFX_GETNUM_BOARDS (GFX_BASE + 1) -#define GFX_GETBOARD_INFO (GFX_BASE + 2) -#define GFX_ATTACH_BOARD (GFX_BASE + 3) -#define GFX_DETACH_BOARD (GFX_BASE + 4) -#define GFX_IS_MANAGED (GFX_BASE + 5) - -#define GFX_MAPALL (GFX_BASE + 10) -#define GFX_LABEL (GFX_BASE + 11) - -#define GFX_INFO_NAME_SIZE 16 -#define GFX_INFO_LABEL_SIZE 16 - -struct gfx_info { - char name [GFX_INFO_NAME_SIZE]; /* board name */ - char label [GFX_INFO_LABEL_SIZE]; /* label name */ - unsigned short int xpmax, ypmax; /* screen resolution */ - unsigned int lenght; /* size of a complete gfx_info for this board */ -}; - -struct gfx_getboardinfo_args { - unsigned int board; /* board number. starting from zero */ - void *buf; /* pointer to gfx_info */ - unsigned int len; /* buffer size of buf */ -}; - -struct gfx_attach_board_args { - unsigned int board; /* board number, starting from zero */ - void *vaddr; /* address where the board registers should be mapped */ -}; - -#ifdef __KERNEL__ -/* umap.c */ -extern void remove_mapping (struct vm_area_struct *vma, struct task_struct *, unsigned long, unsigned long); -extern void *vmalloc_uncached (unsigned long size); -extern int vmap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long size, unsigned long vaddr); -#endif - -#endif /* _ASM_GFX_H */ _ From domen@coderock.org Sun Mar 6 10:48:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:48:26 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:17835 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:13 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id 6BFCE1F241; Sun, 6 Mar 2005 11:46:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 91E7D1F23F; Sun, 6 Mar 2005 11:46:10 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6D0E51F204; Sun, 6 Mar 2005 11:46:00 +0100 (CET) Subject: [patch 5/8] delete unused file include_asm_mips_mipsprom.h To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:46:00 +0100 Message-Id: <20050306104600.6D0E51F204@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/include/asm-mips/mipsprom.h | 74 ----------------------------------------- 1 files changed, 74 deletions(-) diff -L include/asm-mips/mipsprom.h -puN include/asm-mips/mipsprom.h~remove_file-include_asm_mips_mipsprom.h /dev/null --- kj/include/asm-mips/mipsprom.h +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,74 +0,0 @@ -#ifndef __ASM_MIPS_PROM_H -#define __ASM_MIPS_PROM_H - -#define PROM_RESET 0 -#define PROM_EXEC 1 -#define PROM_RESTART 2 -#define PROM_REINIT 3 -#define PROM_REBOOT 4 -#define PROM_AUTOBOOT 5 -#define PROM_OPEN 6 -#define PROM_READ 7 -#define PROM_WRITE 8 -#define PROM_IOCTL 9 -#define PROM_CLOSE 10 -#define PROM_GETCHAR 11 -#define PROM_PUTCHAR 12 -#define PROM_SHOWCHAR 13 /* XXX */ -#define PROM_GETS 14 /* XXX */ -#define PROM_PUTS 15 /* XXX */ -#define PROM_PRINTF 16 /* XXX */ - -/* What are these for? */ -#define PROM_INITPROTO 17 /* XXX */ -#define PROM_PROTOENABLE 18 /* XXX */ -#define PROM_PROTODISABLE 19 /* XXX */ -#define PROM_GETPKT 20 /* XXX */ -#define PROM_PUTPKT 21 /* XXX */ - -/* More PROM shit. Probably has to do with VME RMW cycles??? */ -#define PROM_ORW_RMW 22 /* XXX */ -#define PROM_ORH_RMW 23 /* XXX */ -#define PROM_ORB_RMW 24 /* XXX */ -#define PROM_ANDW_RMW 25 /* XXX */ -#define PROM_ANDH_RMW 26 /* XXX */ -#define PROM_ANDB_RMW 27 /* XXX */ - -/* Cache handling stuff */ -#define PROM_FLUSHCACHE 28 /* XXX */ -#define PROM_CLEARCACHE 29 /* XXX */ - -/* Libc alike stuff */ -#define PROM_SETJMP 30 /* XXX */ -#define PROM_LONGJMP 31 /* XXX */ -#define PROM_BEVUTLB 32 /* XXX */ -#define PROM_GETENV 33 /* XXX */ -#define PROM_SETENV 34 /* XXX */ -#define PROM_ATOB 35 /* XXX */ -#define PROM_STRCMP 36 /* XXX */ -#define PROM_STRLEN 37 /* XXX */ -#define PROM_STRCPY 38 /* XXX */ -#define PROM_STRCAT 39 /* XXX */ - -/* Misc stuff */ -#define PROM_PARSER 40 /* XXX */ -#define PROM_RANGE 41 /* XXX */ -#define PROM_ARGVIZE 42 /* XXX */ -#define PROM_HELP 43 /* XXX */ - -/* Entry points for some PROM commands */ -#define PROM_DUMPCMD 44 /* XXX */ -#define PROM_SETENVCMD 45 /* XXX */ -#define PROM_UNSETENVCMD 46 /* XXX */ -#define PROM_PRINTENVCMD 47 /* XXX */ -#define PROM_BEVEXCEPT 48 /* XXX */ -#define PROM_ENABLECMD 49 /* XXX */ -#define PROM_DISABLECMD 50 /* XXX */ - -#define PROM_CLEARNOFAULT 51 /* XXX */ -#define PROM_NOTIMPLEMENT 52 /* XXX */ - -#define PROM_NV_GET 53 /* XXX */ -#define PROM_NV_SET 54 /* XXX */ - -#endif /* __ASM_MIPS_PROM_H */ _ From domen@coderock.org Sun Mar 6 10:48:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:49:10 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:18347 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:20 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id CF5901F240; Sun, 6 Mar 2005 11:46:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id C7E761F204; Sun, 6 Mar 2005 11:46:16 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 594361F203; Sun, 6 Mar 2005 11:45:57 +0100 (CET) Subject: [patch 4/8] delete unused file include_asm_mips_mach_au1x00_au1100_mmc.h To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:45:57 +0100 Message-Id: <20050306104557.594361F203@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/include/asm-mips/mach-au1x00/au1100_mmc.h | 205 --------------------------- 1 files changed, 205 deletions(-) diff -L include/asm-mips/mach-au1x00/au1100_mmc.h -puN include/asm-mips/mach-au1x00/au1100_mmc.h~remove_file-include_asm_mips_mach_au1x00_au1100_mmc.h /dev/null --- kj/include/asm-mips/mach-au1x00/au1100_mmc.h +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,205 +0,0 @@ -/* - * BRIEF MODULE DESCRIPTION - * Defines for using the MMC/SD controllers on the - * Alchemy Au1100 mips processor. - * - * Copyright (c) 2003 Embedded Edge, LLC. - * Author: Embedded Edge, LLC. - * dan@embeddededge.com or tim@embeddededge.com - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - * - */ -/* - * AU1100 MMC/SD definitions. - * - * From "AMD Alchemy Solutions Au1100 Processor Data Book - Preliminary" - * June, 2003 - */ - -#ifndef __ASM_AU1100_MMC_H -#define __ASM_AU1100_MMC_H - - -#define NUM_AU1100_MMC_CONTROLLERS 2 - - -#define AU1100_SD_IRQ 2 - - -#define SD0_BASE 0xB0600000 -#define SD1_BASE 0xB0680000 - - -/* - * Register offsets. - */ -#define SD_TXPORT (0x0000) -#define SD_RXPORT (0x0004) -#define SD_CONFIG (0x0008) -#define SD_ENABLE (0x000C) -#define SD_CONFIG2 (0x0010) -#define SD_BLKSIZE (0x0014) -#define SD_STATUS (0x0018) -#define SD_DEBUG (0x001C) -#define SD_CMD (0x0020) -#define SD_CMDARG (0x0024) -#define SD_RESP3 (0x0028) -#define SD_RESP2 (0x002C) -#define SD_RESP1 (0x0030) -#define SD_RESP0 (0x0034) -#define SD_TIMEOUT (0x0038) - - -/* - * SD_TXPORT bit definitions. - */ -#define SD_TXPORT_TXD (0x000000ff) - - -/* - * SD_RXPORT bit definitions. - */ -#define SD_RXPORT_RXD (0x000000ff) - - -/* - * SD_CONFIG bit definitions. - */ -#define SD_CONFIG_DIV (0x000001ff) -#define SD_CONFIG_DE (0x00000200) -#define SD_CONFIG_NE (0x00000400) -#define SD_CONFIG_TU (0x00000800) -#define SD_CONFIG_TO (0x00001000) -#define SD_CONFIG_RU (0x00002000) -#define SD_CONFIG_RO (0x00004000) -#define SD_CONFIG_I (0x00008000) -#define SD_CONFIG_CR (0x00010000) -#define SD_CONFIG_RAT (0x00020000) -#define SD_CONFIG_DD (0x00040000) -#define SD_CONFIG_DT (0x00080000) -#define SD_CONFIG_SC (0x00100000) -#define SD_CONFIG_RC (0x00200000) -#define SD_CONFIG_WC (0x00400000) -#define SD_CONFIG_xxx (0x00800000) -#define SD_CONFIG_TH (0x01000000) -#define SD_CONFIG_TE (0x02000000) -#define SD_CONFIG_TA (0x04000000) -#define SD_CONFIG_RH (0x08000000) -#define SD_CONFIG_RA (0x10000000) -#define SD_CONFIG_RF (0x20000000) -#define SD_CONFIG_CD (0x40000000) -#define SD_CONFIG_SI (0x80000000) - - -/* - * SD_ENABLE bit definitions. - */ -#define SD_ENABLE_CE (0x00000001) -#define SD_ENABLE_R (0x00000002) - - -/* - * SD_CONFIG2 bit definitions. - */ -#define SD_CONFIG2_EN (0x00000001) -#define SD_CONFIG2_FF (0x00000002) -#define SD_CONFIG2_xx1 (0x00000004) -#define SD_CONFIG2_DF (0x00000008) -#define SD_CONFIG2_DC (0x00000010) -#define SD_CONFIG2_xx2 (0x000000e0) -#define SD_CONFIG2_WB (0x00000100) -#define SD_CONFIG2_RW (0x00000200) - - -/* - * SD_BLKSIZE bit definitions. - */ -#define SD_BLKSIZE_BS (0x000007ff) -#define SD_BLKSIZE_BS_SHIFT (0) -#define SD_BLKSIZE_BC (0x01ff0000) -#define SD_BLKSIZE_BC_SHIFT (16) - - -/* - * SD_STATUS bit definitions. - */ -#define SD_STATUS_DCRCW (0x00000007) -#define SD_STATUS_xx1 (0x00000008) -#define SD_STATUS_CB (0x00000010) -#define SD_STATUS_DB (0x00000020) -#define SD_STATUS_CF (0x00000040) -#define SD_STATUS_D3 (0x00000080) -#define SD_STATUS_xx2 (0x00000300) -#define SD_STATUS_NE (0x00000400) -#define SD_STATUS_TU (0x00000800) -#define SD_STATUS_TO (0x00001000) -#define SD_STATUS_RU (0x00002000) -#define SD_STATUS_RO (0x00004000) -#define SD_STATUS_I (0x00008000) -#define SD_STATUS_CR (0x00010000) -#define SD_STATUS_RAT (0x00020000) -#define SD_STATUS_DD (0x00040000) -#define SD_STATUS_DT (0x00080000) -#define SD_STATUS_SC (0x00100000) -#define SD_STATUS_RC (0x00200000) -#define SD_STATUS_WC (0x00400000) -#define SD_STATUS_xx3 (0x00800000) -#define SD_STATUS_TH (0x01000000) -#define SD_STATUS_TE (0x02000000) -#define SD_STATUS_TA (0x04000000) -#define SD_STATUS_RH (0x08000000) -#define SD_STATUS_RA (0x10000000) -#define SD_STATUS_RF (0x20000000) -#define SD_STATUS_CD (0x40000000) -#define SD_STATUS_SI (0x80000000) - - -/* - * SD_CMD bit definitions. - */ -#define SD_CMD_GO (0x00000001) -#define SD_CMD_RY (0x00000002) -#define SD_CMD_xx1 (0x0000000c) -#define SD_CMD_CT_MASK (0x000000f0) -#define SD_CMD_CT_0 (0x00000000) -#define SD_CMD_CT_1 (0x00000010) -#define SD_CMD_CT_2 (0x00000020) -#define SD_CMD_CT_3 (0x00000030) -#define SD_CMD_CT_4 (0x00000040) -#define SD_CMD_CT_5 (0x00000050) -#define SD_CMD_CT_6 (0x00000060) -#define SD_CMD_CT_7 (0x00000070) -#define SD_CMD_CI (0x0000ff00) -#define SD_CMD_CI_SHIFT (8) -#define SD_CMD_RT_MASK (0x00ff0000) -#define SD_CMD_RT_0 (0x00000000) -#define SD_CMD_RT_1 (0x00010000) -#define SD_CMD_RT_2 (0x00020000) -#define SD_CMD_RT_3 (0x00030000) -#define SD_CMD_RT_4 (0x00040000) -#define SD_CMD_RT_5 (0x00050000) -#define SD_CMD_RT_6 (0x00060000) -#define SD_CMD_RT_1B (0x00810000) - - -#endif /* __ASM_AU1100_MMC_H */ - _ From domen@coderock.org Sun Mar 6 10:49:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:49:54 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:19371 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:22 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id BAD6B1F23F; Sun, 6 Mar 2005 11:46:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id E03AE1F203; Sun, 6 Mar 2005 11:46:19 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 1D8C11F23D; Sun, 6 Mar 2005 11:46:07 +0100 (CET) Subject: [patch 7/8] mips/bcm1250_tbprof: remove interruptible_sleep_on() usage To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:46:06 +0100 Message-Id: <20050306104607.1D8C11F23D@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove deprecated interruptible_sleep_on() function call and replace with direct wait-queue usage. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/arch/mips/sibyte/sb1250/bcm1250_tbprof.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff -puN arch/mips/sibyte/sb1250/bcm1250_tbprof.c~int_sleep_on-arch_mips_sibyte_sb1250_bcm1250_tbprof arch/mips/sibyte/sb1250/bcm1250_tbprof.c --- kj/arch/mips/sibyte/sb1250/bcm1250_tbprof.c~int_sleep_on-arch_mips_sibyte_sb1250_bcm1250_tbprof 2005-03-05 16:12:04.000000000 +0100 +++ kj-domen/arch/mips/sibyte/sb1250/bcm1250_tbprof.c 2005-03-05 16:12:04.000000000 +0100 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -231,6 +232,7 @@ int sbprof_zbprof_start(struct file *fil int sbprof_zbprof_stop(void) { + DEFINE_WAIT(wait); DBG(printk(DEVNAME ": stopping\n")); if (sbp.tb_enable) { @@ -240,7 +242,9 @@ int sbprof_zbprof_stop(void) this sleep happens. */ if (sbp.tb_armed) { DBG(printk(DEVNAME ": wait for disarm\n")); - interruptible_sleep_on(&sbp.tb_sync); + prepare_to_wait(&sbp.tb_sync, &wait, TASK_INTERRUPTIBLE); + schedule(); + finish_wait(&sbp.tb_sync, &wait); DBG(printk(DEVNAME ": disarm complete\n")); } free_irq(K_INT_TRACE_FREEZE, &sbp); @@ -348,7 +352,10 @@ static int sbprof_tb_ioctl(struct inode error = sbprof_zbprof_stop(); break; case SBPROF_ZBWAITFULL: - interruptible_sleep_on(&sbp.tb_read); + DEFINE_WAIT(wait); + prepare_to_wait(&sbp.tb_read, &wait, TASK_INTERRUPTIBLE); + schedule(); + finish_wait(&sbp.tb_read, &wait); /* XXXKW check if interrupted? */ return put_user(TB_FULL, (int *) arg); default: _ From domen@coderock.org Sun Mar 6 10:50:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:50:36 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:21163 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:46:31 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id EF4231F23F; Sun, 6 Mar 2005 11:46:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id A89CA1F204; Sun, 6 Mar 2005 11:46:28 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 2ACCC1F23E; Sun, 6 Mar 2005 11:46:10 +0100 (CET) Subject: [patch 8/8] __FUNCTION__ string concatenation deprecated To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org, drizzd@aon.at, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:46:09 +0100 Message-Id: <20050306104610.2ACCC1F23E@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips __FUNCTION__ string concatenation is deprecated Signed-off-by: Clemens Buchacher Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/arch/mips/au1000/common/usbdev.c | 4 ++-- kj-domen/drivers/net/gt96100eth.c | 10 +++++----- kj-domen/sound/oss/au1000.c | 2 +- kj-domen/sound/oss/ite8172.c | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff -puN arch/mips/au1000/common/usbdev.c~function-string-arch-mips arch/mips/au1000/common/usbdev.c --- kj/arch/mips/au1000/common/usbdev.c~function-string-arch-mips 2005-03-05 16:09:20.000000000 +0100 +++ kj-domen/arch/mips/au1000/common/usbdev.c 2005-03-05 16:09:20.000000000 +0100 @@ -348,7 +348,7 @@ endpoint_stall(endpoint_t * ep) { u32 cs; - warn(__FUNCTION__); + warn("%s", __FUNCTION__); cs = au_readl(ep->reg->ctrl_stat) | USBDEV_CS_STALL; au_writel(cs, ep->reg->ctrl_stat); @@ -360,7 +360,7 @@ endpoint_unstall(endpoint_t * ep) { u32 cs; - warn(__FUNCTION__); + warn("%s", __FUNCTION__); cs = au_readl(ep->reg->ctrl_stat) & ~USBDEV_CS_STALL; au_writel(cs, ep->reg->ctrl_stat); diff -puN drivers/net/gt96100eth.c~function-string-arch-mips drivers/net/gt96100eth.c --- kj/drivers/net/gt96100eth.c~function-string-arch-mips 2005-03-05 16:09:20.000000000 +0100 +++ kj-domen/drivers/net/gt96100eth.c 2005-03-05 16:09:20.000000000 +0100 @@ -73,7 +73,7 @@ static void dump_rx_desc(int dbg_lvl, st static void dump_skb(int dbg_lvl, struct net_device *dev, struct sk_buff *skb); static void dump_hw_addr(int dbg_lvl, struct net_device *dev, - const char* pfx, unsigned char* addr_str); + const char* pfx, const char* func, unsigned char* addr_str); static void update_stats(struct gt96100_private *gp); static void abort(struct net_device *dev, u32 abort_bits); static void hard_stop(struct net_device *dev); @@ -334,13 +334,13 @@ dump_MII(int dbg_lvl, struct net_device static void dump_hw_addr(int dbg_lvl, struct net_device *dev, const char* pfx, - unsigned char* addr_str) + const char* func, unsigned char* addr_str) { int i; char buf[100], octet[5]; if (dbg_lvl <= GT96100_DEBUG) { - strcpy(buf, pfx); + sprintf(buf, pfx, func); for (i = 0; i < 6; i++) { sprintf(octet, "%2.2x%s", addr_str[i], i<5 ? ":" : "\n"); @@ -708,7 +708,7 @@ static int __init gt96100_probe1(struct info("%s found at 0x%x, irq %d\n", chip_name(gp->chip_rev), gtif->iobase, gtif->irq); - dump_hw_addr(0, dev, "HW Address ", dev->dev_addr); + dump_hw_addr(0, dev, "%s: HW Address ", __FUNCTION__, dev->dev_addr); info("%s chip revision=%d\n", chip_name(gp->chip_rev), gp->chip_rev); info("%s ethernet port %d\n", chip_name(gp->chip_rev), gp->port_num); info("external PHY ID1=0x%04x, ID2=0x%04x\n", phy_id1, phy_id2); @@ -1488,7 +1488,7 @@ gt96100_set_rx_mode(struct net_device *d gt96100_add_hash_entry(dev, dev->dev_addr); for (mcptr = dev->mc_list; mcptr; mcptr = mcptr->next) { - dump_hw_addr(2, dev, __FUNCTION__ ": addr=", + dump_hw_addr(2, dev, "%s: addr=", __FUNCTION__, mcptr->dmi_addr); gt96100_add_hash_entry(dev, mcptr->dmi_addr); } diff -puN sound/oss/au1000.c~function-string-arch-mips sound/oss/au1000.c --- kj/sound/oss/au1000.c~function-string-arch-mips 2005-03-05 16:09:20.000000000 +0100 +++ kj-domen/sound/oss/au1000.c 2005-03-05 16:09:20.000000000 +0100 @@ -1295,7 +1295,7 @@ static int au1000_mmap(struct file *file unsigned long size; int ret = 0; - dbg(__FUNCTION__); + dbg("%s", __FUNCTION__); lock_kernel(); down(&s->sem); diff -puN sound/oss/ite8172.c~function-string-arch-mips sound/oss/ite8172.c --- kj/sound/oss/ite8172.c~function-string-arch-mips 2005-03-05 16:09:20.000000000 +0100 +++ kj-domen/sound/oss/ite8172.c 2005-03-05 16:09:20.000000000 +0100 @@ -1859,7 +1859,7 @@ static int it8172_release(struct inode * struct it8172_state *s = (struct it8172_state *)file->private_data; #ifdef IT8172_VERBOSE_DEBUG - dbg(__FUNCTION__); + dbg("%s", __FUNCTION__); #endif lock_kernel(); if (file->f_mode & FMODE_WRITE) _ From domen@coderock.org Sun Mar 6 10:50:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 10:51:23 +0000 (GMT) Received: from coderock.org ([IPv6:::ffff:193.77.147.115]:22699 "EHLO trashy.coderock.org") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 10:47:04 +0000 Received: by trashy.coderock.org (Postfix, from userid 780) id 9153F1F23D; Sun, 6 Mar 2005 11:47:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 8D3141F203; Sun, 6 Mar 2005 11:46:59 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 73B4D1F1F0; Sun, 6 Mar 2005 11:46:03 +0100 (CET) Subject: [patch 6/8] delete unused file include_asm_mips_riscos_syscall.h To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, domen@coderock.org From: domen@coderock.org Date: Sun, 06 Mar 2005 11:46:03 +0100 Message-Id: <20050306104603.73B4D1F1F0@trashy.coderock.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen@coderock.org Precedence: bulk X-list: linux-mips Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/include/asm-mips/riscos-syscall.h | 979 ----------------------------------- 1 files changed, 979 deletions(-) diff -L include/asm-mips/riscos-syscall.h -puN include/asm-mips/riscos-syscall.h~remove_file-include_asm_mips_riscos_syscall.h /dev/null --- kj/include/asm-mips/riscos-syscall.h +++ /dev/null 2005-03-02 11:34:59.000000000 +0100 @@ -1,979 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 1995, 96, 97, 98, 99, 2000 by Ralf Baechle - */ -#ifndef _ASM_RISCOS_SYSCALL_H -#define _ASM_RISCOS_SYSCALL_H - -/* - * The syscalls 0 - 3999 are reserved for a down to the root syscall - * compatibility with RISC/os and IRIX. We'll see how to deal with the - * various "real" BSD variants like Ultrix, NetBSD ... - */ - -/* - * SVR4 syscalls are in the range from 1 to 999 - */ -#define __NR_SVR4 0 -#define __NR_SVR4_syscall (__NR_SVR4 + 0) -#define __NR_SVR4_exit (__NR_SVR4 + 1) -#define __NR_SVR4_fork (__NR_SVR4 + 2) -#define __NR_SVR4_read (__NR_SVR4 + 3) -#define __NR_SVR4_write (__NR_SVR4 + 4) -#define __NR_SVR4_open (__NR_SVR4 + 5) -#define __NR_SVR4_close (__NR_SVR4 + 6) -#define __NR_SVR4_wait (__NR_SVR4 + 7) -#define __NR_SVR4_creat (__NR_SVR4 + 8) -#define __NR_SVR4_link (__NR_SVR4 + 9) -#define __NR_SVR4_unlink (__NR_SVR4 + 10) -#define __NR_SVR4_exec (__NR_SVR4 + 11) -#define __NR_SVR4_chdir (__NR_SVR4 + 12) -#define __NR_SVR4_gtime (__NR_SVR4 + 13) -#define __NR_SVR4_mknod (__NR_SVR4 + 14) -#define __NR_SVR4_chmod (__NR_SVR4 + 15) -#define __NR_SVR4_chown (__NR_SVR4 + 16) -#define __NR_SVR4_sbreak (__NR_SVR4 + 17) -#define __NR_SVR4_stat (__NR_SVR4 + 18) -#define __NR_SVR4_lseek (__NR_SVR4 + 19) -#define __NR_SVR4_getpid (__NR_SVR4 + 20) -#define __NR_SVR4_mount (__NR_SVR4 + 21) -#define __NR_SVR4_umount (__NR_SVR4 + 22) -#define __NR_SVR4_setuid (__NR_SVR4 + 23) -#define __NR_SVR4_getuid (__NR_SVR4 + 24) -#define __NR_SVR4_stime (__NR_SVR4 + 25) -#define __NR_SVR4_ptrace (__NR_SVR4 + 26) -#define __NR_SVR4_alarm (__NR_SVR4 + 27) -#define __NR_SVR4_fstat (__NR_SVR4 + 28) -#define __NR_SVR4_pause (__NR_SVR4 + 29) -#define __NR_SVR4_utime (__NR_SVR4 + 30) -#define __NR_SVR4_stty (__NR_SVR4 + 31) -#define __NR_SVR4_gtty (__NR_SVR4 + 32) -#define __NR_SVR4_access (__NR_SVR4 + 33) -#define __NR_SVR4_nice (__NR_SVR4 + 34) -#define __NR_SVR4_statfs (__NR_SVR4 + 35) -#define __NR_SVR4_sync (__NR_SVR4 + 36) -#define __NR_SVR4_kill (__NR_SVR4 + 37) -#define __NR_SVR4_fstatfs (__NR_SVR4 + 38) -#define __NR_SVR4_setpgrp (__NR_SVR4 + 39) -#define __NR_SVR4_cxenix (__NR_SVR4 + 40) -#define __NR_SVR4_dup (__NR_SVR4 + 41) -#define __NR_SVR4_pipe (__NR_SVR4 + 42) -#define __NR_SVR4_times (__NR_SVR4 + 43) -#define __NR_SVR4_profil (__NR_SVR4 + 44) -#define __NR_SVR4_plock (__NR_SVR4 + 45) -#define __NR_SVR4_setgid (__NR_SVR4 + 46) -#define __NR_SVR4_getgid (__NR_SVR4 + 47) -#define __NR_SVR4_sig (__NR_SVR4 + 48) -#define __NR_SVR4_msgsys (__NR_SVR4 + 49) -#define __NR_SVR4_sysmips (__NR_SVR4 + 50) -#define __NR_SVR4_sysacct (__NR_SVR4 + 51) -#define __NR_SVR4_shmsys (__NR_SVR4 + 52) -#define __NR_SVR4_semsys (__NR_SVR4 + 53) -#define __NR_SVR4_ioctl (__NR_SVR4 + 54) -#define __NR_SVR4_uadmin (__NR_SVR4 + 55) -#define __NR_SVR4_exch (__NR_SVR4 + 56) -#define __NR_SVR4_utssys (__NR_SVR4 + 57) -#define __NR_SVR4_fsync (__NR_SVR4 + 58) -#define __NR_SVR4_exece (__NR_SVR4 + 59) -#define __NR_SVR4_umask (__NR_SVR4 + 60) -#define __NR_SVR4_chroot (__NR_SVR4 + 61) -#define __NR_SVR4_fcntl (__NR_SVR4 + 62) -#define __NR_SVR4_ulimit (__NR_SVR4 + 63) -#define __NR_SVR4_reserved1 (__NR_SVR4 + 64) -#define __NR_SVR4_reserved2 (__NR_SVR4 + 65) -#define __NR_SVR4_reserved3 (__NR_SVR4 + 66) -#define __NR_SVR4_reserved4 (__NR_SVR4 + 67) -#define __NR_SVR4_reserved5 (__NR_SVR4 + 68) -#define __NR_SVR4_reserved6 (__NR_SVR4 + 69) -#define __NR_SVR4_advfs (__NR_SVR4 + 70) -#define __NR_SVR4_unadvfs (__NR_SVR4 + 71) -#define __NR_SVR4_unused1 (__NR_SVR4 + 72) -#define __NR_SVR4_unused2 (__NR_SVR4 + 73) -#define __NR_SVR4_rfstart (__NR_SVR4 + 74) -#define __NR_SVR4_unused3 (__NR_SVR4 + 75) -#define __NR_SVR4_rdebug (__NR_SVR4 + 76) -#define __NR_SVR4_rfstop (__NR_SVR4 + 77) -#define __NR_SVR4_rfsys (__NR_SVR4 + 78) -#define __NR_SVR4_rmdir (__NR_SVR4 + 79) -#define __NR_SVR4_mkdir (__NR_SVR4 + 80) -#define __NR_SVR4_getdents (__NR_SVR4 + 81) -#define __NR_SVR4_libattach (__NR_SVR4 + 82) -#define __NR_SVR4_libdetach (__NR_SVR4 + 83) -#define __NR_SVR4_sysfs (__NR_SVR4 + 84) -#define __NR_SVR4_getmsg (__NR_SVR4 + 85) -#define __NR_SVR4_putmsg (__NR_SVR4 + 86) -#define __NR_SVR4_poll (__NR_SVR4 + 87) -#define __NR_SVR4_lstat (__NR_SVR4 + 88) -#define __NR_SVR4_symlink (__NR_SVR4 + 89) -#define __NR_SVR4_readlink (__NR_SVR4 + 90) -#define __NR_SVR4_setgroups (__NR_SVR4 + 91) -#define __NR_SVR4_getgroups (__NR_SVR4 + 92) -#define __NR_SVR4_fchmod (__NR_SVR4 + 93) -#define __NR_SVR4_fchown (__NR_SVR4 + 94) -#define __NR_SVR4_sigprocmask (__NR_SVR4 + 95) -#define __NR_SVR4_sigsuspend (__NR_SVR4 + 96) -#define __NR_SVR4_sigaltstack (__NR_SVR4 + 97) -#define __NR_SVR4_sigaction (__NR_SVR4 + 98) -#define __NR_SVR4_sigpending (__NR_SVR4 + 99) -#define __NR_SVR4_setcontext (__NR_SVR4 + 100) -#define __NR_SVR4_evsys (__NR_SVR4 + 101) -#define __NR_SVR4_evtrapret (__NR_SVR4 + 102) -#define __NR_SVR4_statvfs (__NR_SVR4 + 103) -#define __NR_SVR4_fstatvfs (__NR_SVR4 + 104) -#define __NR_SVR4_reserved7 (__NR_SVR4 + 105) -#define __NR_SVR4_nfssys (__NR_SVR4 + 106) -#define __NR_SVR4_waitid (__NR_SVR4 + 107) -#define __NR_SVR4_sigsendset (__NR_SVR4 + 108) -#define __NR_SVR4_hrtsys (__NR_SVR4 + 109) -#define __NR_SVR4_acancel (__NR_SVR4 + 110) -#define __NR_SVR4_async (__NR_SVR4 + 111) -#define __NR_SVR4_priocntlset (__NR_SVR4 + 112) -#define __NR_SVR4_pathconf (__NR_SVR4 + 113) -#define __NR_SVR4_mincore (__NR_SVR4 + 114) -#define __NR_SVR4_mmap (__NR_SVR4 + 115) -#define __NR_SVR4_mprotect (__NR_SVR4 + 116) -#define __NR_SVR4_munmap (__NR_SVR4 + 117) -#define __NR_SVR4_fpathconf (__NR_SVR4 + 118) -#define __NR_SVR4_vfork (__NR_SVR4 + 119) -#define __NR_SVR4_fchdir (__NR_SVR4 + 120) -#define __NR_SVR4_readv (__NR_SVR4 + 121) -#define __NR_SVR4_writev (__NR_SVR4 + 122) -#define __NR_SVR4_xstat (__NR_SVR4 + 123) -#define __NR_SVR4_lxstat (__NR_SVR4 + 124) -#define __NR_SVR4_fxstat (__NR_SVR4 + 125) -#define __NR_SVR4_xmknod (__NR_SVR4 + 126) -#define __NR_SVR4_clocal (__NR_SVR4 + 127) -#define __NR_SVR4_setrlimit (__NR_SVR4 + 128) -#define __NR_SVR4_getrlimit (__NR_SVR4 + 129) -#define __NR_SVR4_lchown (__NR_SVR4 + 130) -#define __NR_SVR4_memcntl (__NR_SVR4 + 131) -#define __NR_SVR4_getpmsg (__NR_SVR4 + 132) -#define __NR_SVR4_putpmsg (__NR_SVR4 + 133) -#define __NR_SVR4_rename (__NR_SVR4 + 134) -#define __NR_SVR4_nuname (__NR_SVR4 + 135) -#define __NR_SVR4_setegid (__NR_SVR4 + 136) -#define __NR_SVR4_sysconf (__NR_SVR4 + 137) -#define __NR_SVR4_adjtime (__NR_SVR4 + 138) -#define __NR_SVR4_sysinfo (__NR_SVR4 + 139) -#define __NR_SVR4_reserved8 (__NR_SVR4 + 140) -#define __NR_SVR4_seteuid (__NR_SVR4 + 141) -#define __NR_SVR4_PYRAMID_statis (__NR_SVR4 + 142) -#define __NR_SVR4_PYRAMID_tuning (__NR_SVR4 + 143) -#define __NR_SVR4_PYRAMID_forcerr (__NR_SVR4 + 144) -#define __NR_SVR4_PYRAMID_mpcntl (__NR_SVR4 + 145) -#define __NR_SVR4_reserved9 (__NR_SVR4 + 146) -#define __NR_SVR4_reserved10 (__NR_SVR4 + 147) -#define __NR_SVR4_reserved11 (__NR_SVR4 + 148) -#define __NR_SVR4_reserved12 (__NR_SVR4 + 149) -#define __NR_SVR4_reserved13 (__NR_SVR4 + 150) -#define __NR_SVR4_reserved14 (__NR_SVR4 + 151) -#define __NR_SVR4_reserved15 (__NR_SVR4 + 152) -#define __NR_SVR4_reserved16 (__NR_SVR4 + 153) -#define __NR_SVR4_reserved17 (__NR_SVR4 + 154) -#define __NR_SVR4_reserved18 (__NR_SVR4 + 155) -#define __NR_SVR4_reserved19 (__NR_SVR4 + 156) -#define __NR_SVR4_reserved20 (__NR_SVR4 + 157) -#define __NR_SVR4_reserved21 (__NR_SVR4 + 158) -#define __NR_SVR4_reserved22 (__NR_SVR4 + 159) -#define __NR_SVR4_reserved23 (__NR_SVR4 + 160) -#define __NR_SVR4_reserved24 (__NR_SVR4 + 161) -#define __NR_SVR4_reserved25 (__NR_SVR4 + 162) -#define __NR_SVR4_reserved26 (__NR_SVR4 + 163) -#define __NR_SVR4_reserved27 (__NR_SVR4 + 164) -#define __NR_SVR4_reserved28 (__NR_SVR4 + 165) -#define __NR_SVR4_reserved29 (__NR_SVR4 + 166) -#define __NR_SVR4_reserved30 (__NR_SVR4 + 167) -#define __NR_SVR4_reserved31 (__NR_SVR4 + 168) -#define __NR_SVR4_reserved32 (__NR_SVR4 + 169) -#define __NR_SVR4_reserved33 (__NR_SVR4 + 170) -#define __NR_SVR4_reserved34 (__NR_SVR4 + 171) -#define __NR_SVR4_reserved35 (__NR_SVR4 + 172) -#define __NR_SVR4_reserved36 (__NR_SVR4 + 173) -#define __NR_SVR4_reserved37 (__NR_SVR4 + 174) -#define __NR_SVR4_reserved38 (__NR_SVR4 + 175) -#define __NR_SVR4_reserved39 (__NR_SVR4 + 176) -#define __NR_SVR4_reserved40 (__NR_SVR4 + 177) -#define __NR_SVR4_reserved41 (__NR_SVR4 + 178) -#define __NR_SVR4_reserved42 (__NR_SVR4 + 179) -#define __NR_SVR4_reserved43 (__NR_SVR4 + 180) -#define __NR_SVR4_reserved44 (__NR_SVR4 + 181) -#define __NR_SVR4_reserved45 (__NR_SVR4 + 182) -#define __NR_SVR4_reserved46 (__NR_SVR4 + 183) -#define __NR_SVR4_reserved47 (__NR_SVR4 + 184) -#define __NR_SVR4_reserved48 (__NR_SVR4 + 185) -#define __NR_SVR4_reserved49 (__NR_SVR4 + 186) -#define __NR_SVR4_reserved50 (__NR_SVR4 + 187) -#define __NR_SVR4_reserved51 (__NR_SVR4 + 188) -#define __NR_SVR4_reserved52 (__NR_SVR4 + 189) -#define __NR_SVR4_reserved53 (__NR_SVR4 + 190) -#define __NR_SVR4_reserved54 (__NR_SVR4 + 191) -#define __NR_SVR4_reserved55 (__NR_SVR4 + 192) -#define __NR_SVR4_reserved56 (__NR_SVR4 + 193) -#define __NR_SVR4_reserved57 (__NR_SVR4 + 194) -#define __NR_SVR4_reserved58 (__NR_SVR4 + 195) -#define __NR_SVR4_reserved59 (__NR_SVR4 + 196) -#define __NR_SVR4_reserved60 (__NR_SVR4 + 197) -#define __NR_SVR4_reserved61 (__NR_SVR4 + 198) -#define __NR_SVR4_reserved62 (__NR_SVR4 + 199) -#define __NR_SVR4_reserved63 (__NR_SVR4 + 200) -#define __NR_SVR4_aread (__NR_SVR4 + 201) -#define __NR_SVR4_awrite (__NR_SVR4 + 202) -#define __NR_SVR4_listio (__NR_SVR4 + 203) -#define __NR_SVR4_mips_acancel (__NR_SVR4 + 204) -#define __NR_SVR4_astatus (__NR_SVR4 + 205) -#define __NR_SVR4_await (__NR_SVR4 + 206) -#define __NR_SVR4_areadv (__NR_SVR4 + 207) -#define __NR_SVR4_awritev (__NR_SVR4 + 208) -#define __NR_SVR4_MIPS_reserved1 (__NR_SVR4 + 209) -#define __NR_SVR4_MIPS_reserved2 (__NR_SVR4 + 210) -#define __NR_SVR4_MIPS_reserved3 (__NR_SVR4 + 211) -#define __NR_SVR4_MIPS_reserved4 (__NR_SVR4 + 212) -#define __NR_SVR4_MIPS_reserved5 (__NR_SVR4 + 213) -#define __NR_SVR4_MIPS_reserved6 (__NR_SVR4 + 214) -#define __NR_SVR4_MIPS_reserved7 (__NR_SVR4 + 215) -#define __NR_SVR4_MIPS_reserved8 (__NR_SVR4 + 216) -#define __NR_SVR4_MIPS_reserved9 (__NR_SVR4 + 217) -#define __NR_SVR4_MIPS_reserved10 (__NR_SVR4 + 218) -#define __NR_SVR4_MIPS_reserved11 (__NR_SVR4 + 219) -#define __NR_SVR4_MIPS_reserved12 (__NR_SVR4 + 220) -#define __NR_SVR4_CDC_reserved1 (__NR_SVR4 + 221) -#define __NR_SVR4_CDC_reserved2 (__NR_SVR4 + 222) -#define __NR_SVR4_CDC_reserved3 (__NR_SVR4 + 223) -#define __NR_SVR4_CDC_reserved4 (__NR_SVR4 + 224) -#define __NR_SVR4_CDC_reserved5 (__NR_SVR4 + 225) -#define __NR_SVR4_CDC_reserved6 (__NR_SVR4 + 226) -#define __NR_SVR4_CDC_reserved7 (__NR_SVR4 + 227) -#define __NR_SVR4_CDC_reserved8 (__NR_SVR4 + 228) -#define __NR_SVR4_CDC_reserved9 (__NR_SVR4 + 229) -#define __NR_SVR4_CDC_reserved10 (__NR_SVR4 + 230) -#define __NR_SVR4_CDC_reserved11 (__NR_SVR4 + 231) -#define __NR_SVR4_CDC_reserved12 (__NR_SVR4 + 232) -#define __NR_SVR4_CDC_reserved13 (__NR_SVR4 + 233) -#define __NR_SVR4_CDC_reserved14 (__NR_SVR4 + 234) -#define __NR_SVR4_CDC_reserved15 (__NR_SVR4 + 235) -#define __NR_SVR4_CDC_reserved16 (__NR_SVR4 + 236) -#define __NR_SVR4_CDC_reserved17 (__NR_SVR4 + 237) -#define __NR_SVR4_CDC_reserved18 (__NR_SVR4 + 238) -#define __NR_SVR4_CDC_reserved19 (__NR_SVR4 + 239) -#define __NR_SVR4_CDC_reserved20 (__NR_SVR4 + 240) - -/* - * SYS V syscalls are in the range from 1000 to 1999 - */ -#define __NR_SYSV 1000 -#define __NR_SYSV_syscall (__NR_SYSV + 0) -#define __NR_SYSV_exit (__NR_SYSV + 1) -#define __NR_SYSV_fork (__NR_SYSV + 2) -#define __NR_SYSV_read (__NR_SYSV + 3) -#define __NR_SYSV_write (__NR_SYSV + 4) -#define __NR_SYSV_open (__NR_SYSV + 5) -#define __NR_SYSV_close (__NR_SYSV + 6) -#define __NR_SYSV_wait (__NR_SYSV + 7) -#define __NR_SYSV_creat (__NR_SYSV + 8) -#define __NR_SYSV_link (__NR_SYSV + 9) -#define __NR_SYSV_unlink (__NR_SYSV + 10) -#define __NR_SYSV_execv (__NR_SYSV + 11) -#define __NR_SYSV_chdir (__NR_SYSV + 12) -#define __NR_SYSV_time (__NR_SYSV + 13) -#define __NR_SYSV_mknod (__NR_SYSV + 14) -#define __NR_SYSV_chmod (__NR_SYSV + 15) -#define __NR_SYSV_chown (__NR_SYSV + 16) -#define __NR_SYSV_brk (__NR_SYSV + 17) -#define __NR_SYSV_stat (__NR_SYSV + 18) -#define __NR_SYSV_lseek (__NR_SYSV + 19) -#define __NR_SYSV_getpid (__NR_SYSV + 20) -#define __NR_SYSV_mount (__NR_SYSV + 21) -#define __NR_SYSV_umount (__NR_SYSV + 22) -#define __NR_SYSV_setuid (__NR_SYSV + 23) -#define __NR_SYSV_getuid (__NR_SYSV + 24) -#define __NR_SYSV_stime (__NR_SYSV + 25) -#define __NR_SYSV_ptrace (__NR_SYSV + 26) -#define __NR_SYSV_alarm (__NR_SYSV + 27) -#define __NR_SYSV_fstat (__NR_SYSV + 28) -#define __NR_SYSV_pause (__NR_SYSV + 29) -#define __NR_SYSV_utime (__NR_SYSV + 30) -#define __NR_SYSV_stty (__NR_SYSV + 31) -#define __NR_SYSV_gtty (__NR_SYSV + 32) -#define __NR_SYSV_access (__NR_SYSV + 33) -#define __NR_SYSV_nice (__NR_SYSV + 34) -#define __NR_SYSV_statfs (__NR_SYSV + 35) -#define __NR_SYSV_sync (__NR_SYSV + 36) -#define __NR_SYSV_kill (__NR_SYSV + 37) -#define __NR_SYSV_fstatfs (__NR_SYSV + 38) -#define __NR_SYSV_setpgrp (__NR_SYSV + 39) -#define __NR_SYSV_syssgi (__NR_SYSV + 40) -#define __NR_SYSV_dup (__NR_SYSV + 41) -#define __NR_SYSV_pipe (__NR_SYSV + 42) -#define __NR_SYSV_times (__NR_SYSV + 43) -#define __NR_SYSV_profil (__NR_SYSV + 44) -#define __NR_SYSV_plock (__NR_SYSV + 45) -#define __NR_SYSV_setgid (__NR_SYSV + 46) -#define __NR_SYSV_getgid (__NR_SYSV + 47) -#define __NR_SYSV_sig (__NR_SYSV + 48) -#define __NR_SYSV_msgsys (__NR_SYSV + 49) -#define __NR_SYSV_sysmips (__NR_SYSV + 50) -#define __NR_SYSV_acct (__NR_SYSV + 51) -#define __NR_SYSV_shmsys (__NR_SYSV + 52) -#define __NR_SYSV_semsys (__NR_SYSV + 53) -#define __NR_SYSV_ioctl (__NR_SYSV + 54) -#define __NR_SYSV_uadmin (__NR_SYSV + 55) -#define __NR_SYSV_sysmp (__NR_SYSV + 56) -#define __NR_SYSV_utssys (__NR_SYSV + 57) -#define __NR_SYSV_USG_reserved1 (__NR_SYSV + 58) -#define __NR_SYSV_execve (__NR_SYSV + 59) -#define __NR_SYSV_umask (__NR_SYSV + 60) -#define __NR_SYSV_chroot (__NR_SYSV + 61) -#define __NR_SYSV_fcntl (__NR_SYSV + 62) -#define __NR_SYSV_ulimit (__NR_SYSV + 63) -#define __NR_SYSV_SAFARI4_reserved1 (__NR_SYSV + 64) -#define __NR_SYSV_SAFARI4_reserved2 (__NR_SYSV + 65) -#define __NR_SYSV_SAFARI4_reserved3 (__NR_SYSV + 66) -#define __NR_SYSV_SAFARI4_reserved4 (__NR_SYSV + 67) -#define __NR_SYSV_SAFARI4_reserved5 (__NR_SYSV + 68) -#define __NR_SYSV_SAFARI4_reserved6 (__NR_SYSV + 69) -#define __NR_SYSV_advfs (__NR_SYSV + 70) -#define __NR_SYSV_unadvfs (__NR_SYSV + 71) -#define __NR_SYSV_rmount (__NR_SYSV + 72) -#define __NR_SYSV_rumount (__NR_SYSV + 73) -#define __NR_SYSV_rfstart (__NR_SYSV + 74) -#define __NR_SYSV_getrlimit64 (__NR_SYSV + 75) -#define __NR_SYSV_setrlimit64 (__NR_SYSV + 76) -#define __NR_SYSV_nanosleep (__NR_SYSV + 77) -#define __NR_SYSV_lseek64 (__NR_SYSV + 78) -#define __NR_SYSV_rmdir (__NR_SYSV + 79) -#define __NR_SYSV_mkdir (__NR_SYSV + 80) -#define __NR_SYSV_getdents (__NR_SYSV + 81) -#define __NR_SYSV_sginap (__NR_SYSV + 82) -#define __NR_SYSV_sgikopt (__NR_SYSV + 83) -#define __NR_SYSV_sysfs (__NR_SYSV + 84) -#define __NR_SYSV_getmsg (__NR_SYSV + 85) -#define __NR_SYSV_putmsg (__NR_SYSV + 86) -#define __NR_SYSV_poll (__NR_SYSV + 87) -#define __NR_SYSV_sigreturn (__NR_SYSV + 88) -#define __NR_SYSV_accept (__NR_SYSV + 89) -#define __NR_SYSV_bind (__NR_SYSV + 90) -#define __NR_SYSV_connect (__NR_SYSV + 91) -#define __NR_SYSV_gethostid (__NR_SYSV + 92) -#define __NR_SYSV_getpeername (__NR_SYSV + 93) -#define __NR_SYSV_getsockname (__NR_SYSV + 94) -#define __NR_SYSV_getsockopt (__NR_SYSV + 95) -#define __NR_SYSV_listen (__NR_SYSV + 96) -#define __NR_SYSV_recv (__NR_SYSV + 97) -#define __NR_SYSV_recvfrom (__NR_SYSV + 98) -#define __NR_SYSV_recvmsg (__NR_SYSV + 99) -#define __NR_SYSV_select (__NR_SYSV + 100) -#define __NR_SYSV_send (__NR_SYSV + 101) -#define __NR_SYSV_sendmsg (__NR_SYSV + 102) -#define __NR_SYSV_sendto (__NR_SYSV + 103) -#define __NR_SYSV_sethostid (__NR_SYSV + 104) -#define __NR_SYSV_setsockopt (__NR_SYSV + 105) -#define __NR_SYSV_shutdown (__NR_SYSV + 106) -#define __NR_SYSV_socket (__NR_SYSV + 107) -#define __NR_SYSV_gethostname (__NR_SYSV + 108) -#define __NR_SYSV_sethostname (__NR_SYSV + 109) -#define __NR_SYSV_getdomainname (__NR_SYSV + 110) -#define __NR_SYSV_setdomainname (__NR_SYSV + 111) -#define __NR_SYSV_truncate (__NR_SYSV + 112) -#define __NR_SYSV_ftruncate (__NR_SYSV + 113) -#define __NR_SYSV_rename (__NR_SYSV + 114) -#define __NR_SYSV_symlink (__NR_SYSV + 115) -#define __NR_SYSV_readlink (__NR_SYSV + 116) -#define __NR_SYSV_lstat (__NR_SYSV + 117) -#define __NR_SYSV_nfsmount (__NR_SYSV + 118) -#define __NR_SYSV_nfssvc (__NR_SYSV + 119) -#define __NR_SYSV_getfh (__NR_SYSV + 120) -#define __NR_SYSV_async_daemon (__NR_SYSV + 121) -#define __NR_SYSV_exportfs (__NR_SYSV + 122) -#define __NR_SYSV_setregid (__NR_SYSV + 123) -#define __NR_SYSV_setreuid (__NR_SYSV + 124) -#define __NR_SYSV_getitimer (__NR_SYSV + 125) -#define __NR_SYSV_setitimer (__NR_SYSV + 126) -#define __NR_SYSV_adjtime (__NR_SYSV + 127) -#define __NR_SYSV_BSD_getime (__NR_SYSV + 128) -#define __NR_SYSV_sproc (__NR_SYSV + 129) -#define __NR_SYSV_prctl (__NR_SYSV + 130) -#define __NR_SYSV_procblk (__NR_SYSV + 131) -#define __NR_SYSV_sprocsp (__NR_SYSV + 132) -#define __NR_SYSV_sgigsc (__NR_SYSV + 133) -#define __NR_SYSV_mmap (__NR_SYSV + 134) -#define __NR_SYSV_munmap (__NR_SYSV + 135) -#define __NR_SYSV_mprotect (__NR_SYSV + 136) -#define __NR_SYSV_msync (__NR_SYSV + 137) -#define __NR_SYSV_madvise (__NR_SYSV + 138) -#define __NR_SYSV_pagelock (__NR_SYSV + 139) -#define __NR_SYSV_getpagesize (__NR_SYSV + 140) -#define __NR_SYSV_quotactl (__NR_SYSV + 141) -#define __NR_SYSV_libdetach (__NR_SYSV + 142) -#define __NR_SYSV_BSDgetpgrp (__NR_SYSV + 143) -#define __NR_SYSV_BSDsetpgrp (__NR_SYSV + 144) -#define __NR_SYSV_vhangup (__NR_SYSV + 145) -#define __NR_SYSV_fsync (__NR_SYSV + 146) -#define __NR_SYSV_fchdir (__NR_SYSV + 147) -#define __NR_SYSV_getrlimit (__NR_SYSV + 148) -#define __NR_SYSV_setrlimit (__NR_SYSV + 149) -#define __NR_SYSV_cacheflush (__NR_SYSV + 150) -#define __NR_SYSV_cachectl (__NR_SYSV + 151) -#define __NR_SYSV_fchown (__NR_SYSV + 152) -#define __NR_SYSV_fchmod (__NR_SYSV + 153) -#define __NR_SYSV_wait3 (__NR_SYSV + 154) -#define __NR_SYSV_socketpair (__NR_SYSV + 155) -#define __NR_SYSV_sysinfo (__NR_SYSV + 156) -#define __NR_SYSV_nuname (__NR_SYSV + 157) -#define __NR_SYSV_xstat (__NR_SYSV + 158) -#define __NR_SYSV_lxstat (__NR_SYSV + 159) -#define __NR_SYSV_fxstat (__NR_SYSV + 160) -#define __NR_SYSV_xmknod (__NR_SYSV + 161) -#define __NR_SYSV_ksigaction (__NR_SYSV + 162) -#define __NR_SYSV_sigpending (__NR_SYSV + 163) -#define __NR_SYSV_sigprocmask (__NR_SYSV + 164) -#define __NR_SYSV_sigsuspend (__NR_SYSV + 165) -#define __NR_SYSV_sigpoll (__NR_SYSV + 166) -#define __NR_SYSV_swapctl (__NR_SYSV + 167) -#define __NR_SYSV_getcontext (__NR_SYSV + 168) -#define __NR_SYSV_setcontext (__NR_SYSV + 169) -#define __NR_SYSV_waitsys (__NR_SYSV + 170) -#define __NR_SYSV_sigstack (__NR_SYSV + 171) -#define __NR_SYSV_sigaltstack (__NR_SYSV + 172) -#define __NR_SYSV_sigsendset (__NR_SYSV + 173) -#define __NR_SYSV_statvfs (__NR_SYSV + 174) -#define __NR_SYSV_fstatvfs (__NR_SYSV + 175) -#define __NR_SYSV_getpmsg (__NR_SYSV + 176) -#define __NR_SYSV_putpmsg (__NR_SYSV + 177) -#define __NR_SYSV_lchown (__NR_SYSV + 178) -#define __NR_SYSV_priocntl (__NR_SYSV + 179) -#define __NR_SYSV_ksigqueue (__NR_SYSV + 180) -#define __NR_SYSV_readv (__NR_SYSV + 181) -#define __NR_SYSV_writev (__NR_SYSV + 182) -#define __NR_SYSV_truncate64 (__NR_SYSV + 183) -#define __NR_SYSV_ftruncate64 (__NR_SYSV + 184) -#define __NR_SYSV_mmap64 (__NR_SYSV + 185) -#define __NR_SYSV_dmi (__NR_SYSV + 186) -#define __NR_SYSV_pread (__NR_SYSV + 187) -#define __NR_SYSV_pwrite (__NR_SYSV + 188) - -/* - * BSD 4.3 syscalls are in the range from 2000 to 2999 - */ -#define __NR_BSD43 2000 -#define __NR_BSD43_syscall (__NR_BSD43 + 0) -#define __NR_BSD43_exit (__NR_BSD43 + 1) -#define __NR_BSD43_fork (__NR_BSD43 + 2) -#define __NR_BSD43_read (__NR_BSD43 + 3) -#define __NR_BSD43_write (__NR_BSD43 + 4) -#define __NR_BSD43_open (__NR_BSD43 + 5) -#define __NR_BSD43_close (__NR_BSD43 + 6) -#define __NR_BSD43_wait (__NR_BSD43 + 7) -#define __NR_BSD43_creat (__NR_BSD43 + 8) -#define __NR_BSD43_link (__NR_BSD43 + 9) -#define __NR_BSD43_unlink (__NR_BSD43 + 10) -#define __NR_BSD43_exec (__NR_BSD43 + 11) -#define __NR_BSD43_chdir (__NR_BSD43 + 12) -#define __NR_BSD43_time (__NR_BSD43 + 13) -#define __NR_BSD43_mknod (__NR_BSD43 + 14) -#define __NR_BSD43_chmod (__NR_BSD43 + 15) -#define __NR_BSD43_chown (__NR_BSD43 + 16) -#define __NR_BSD43_sbreak (__NR_BSD43 + 17) -#define __NR_BSD43_oldstat (__NR_BSD43 + 18) -#define __NR_BSD43_lseek (__NR_BSD43 + 19) -#define __NR_BSD43_getpid (__NR_BSD43 + 20) -#define __NR_BSD43_oldmount (__NR_BSD43 + 21) -#define __NR_BSD43_umount (__NR_BSD43 + 22) -#define __NR_BSD43_setuid (__NR_BSD43 + 23) -#define __NR_BSD43_getuid (__NR_BSD43 + 24) -#define __NR_BSD43_stime (__NR_BSD43 + 25) -#define __NR_BSD43_ptrace (__NR_BSD43 + 26) -#define __NR_BSD43_alarm (__NR_BSD43 + 27) -#define __NR_BSD43_oldfstat (__NR_BSD43 + 28) -#define __NR_BSD43_pause (__NR_BSD43 + 29) -#define __NR_BSD43_utime (__NR_BSD43 + 30) -#define __NR_BSD43_stty (__NR_BSD43 + 31) -#define __NR_BSD43_gtty (__NR_BSD43 + 32) -#define __NR_BSD43_access (__NR_BSD43 + 33) -#define __NR_BSD43_nice (__NR_BSD43 + 34) -#define __NR_BSD43_ftime (__NR_BSD43 + 35) -#define __NR_BSD43_sync (__NR_BSD43 + 36) -#define __NR_BSD43_kill (__NR_BSD43 + 37) -#define __NR_BSD43_stat (__NR_BSD43 + 38) -#define __NR_BSD43_oldsetpgrp (__NR_BSD43 + 39) -#define __NR_BSD43_lstat (__NR_BSD43 + 40) -#define __NR_BSD43_dup (__NR_BSD43 + 41) -#define __NR_BSD43_pipe (__NR_BSD43 + 42) -#define __NR_BSD43_times (__NR_BSD43 + 43) -#define __NR_BSD43_profil (__NR_BSD43 + 44) -#define __NR_BSD43_msgsys (__NR_BSD43 + 45) -#define __NR_BSD43_setgid (__NR_BSD43 + 46) -#define __NR_BSD43_getgid (__NR_BSD43 + 47) -#define __NR_BSD43_ssig (__NR_BSD43 + 48) -#define __NR_BSD43_reserved1 (__NR_BSD43 + 49) -#define __NR_BSD43_reserved2 (__NR_BSD43 + 50) -#define __NR_BSD43_sysacct (__NR_BSD43 + 51) -#define __NR_BSD43_phys (__NR_BSD43 + 52) -#define __NR_BSD43_lock (__NR_BSD43 + 53) -#define __NR_BSD43_ioctl (__NR_BSD43 + 54) -#define __NR_BSD43_reboot (__NR_BSD43 + 55) -#define __NR_BSD43_mpxchan (__NR_BSD43 + 56) -#define __NR_BSD43_symlink (__NR_BSD43 + 57) -#define __NR_BSD43_readlink (__NR_BSD43 + 58) -#define __NR_BSD43_execve (__NR_BSD43 + 59) -#define __NR_BSD43_umask (__NR_BSD43 + 60) -#define __NR_BSD43_chroot (__NR_BSD43 + 61) -#define __NR_BSD43_fstat (__NR_BSD43 + 62) -#define __NR_BSD43_reserved3 (__NR_BSD43 + 63) -#define __NR_BSD43_getpagesize (__NR_BSD43 + 64) -#define __NR_BSD43_mremap (__NR_BSD43 + 65) -#define __NR_BSD43_vfork (__NR_BSD43 + 66) -#define __NR_BSD43_vread (__NR_BSD43 + 67) -#define __NR_BSD43_vwrite (__NR_BSD43 + 68) -#define __NR_BSD43_sbrk (__NR_BSD43 + 69) -#define __NR_BSD43_sstk (__NR_BSD43 + 70) -#define __NR_BSD43_mmap (__NR_BSD43 + 71) -#define __NR_BSD43_vadvise (__NR_BSD43 + 72) -#define __NR_BSD43_munmap (__NR_BSD43 + 73) -#define __NR_BSD43_mprotect (__NR_BSD43 + 74) -#define __NR_BSD43_madvise (__NR_BSD43 + 75) -#define __NR_BSD43_vhangup (__NR_BSD43 + 76) -#define __NR_BSD43_vlimit (__NR_BSD43 + 77) -#define __NR_BSD43_mincore (__NR_BSD43 + 78) -#define __NR_BSD43_getgroups (__NR_BSD43 + 79) -#define __NR_BSD43_setgroups (__NR_BSD43 + 80) -#define __NR_BSD43_getpgrp (__NR_BSD43 + 81) -#define __NR_BSD43_setpgrp (__NR_BSD43 + 82) -#define __NR_BSD43_setitimer (__NR_BSD43 + 83) -#define __NR_BSD43_wait3 (__NR_BSD43 + 84) -#define __NR_BSD43_swapon (__NR_BSD43 + 85) -#define __NR_BSD43_getitimer (__NR_BSD43 + 86) -#define __NR_BSD43_gethostname (__NR_BSD43 + 87) -#define __NR_BSD43_sethostname (__NR_BSD43 + 88) -#define __NR_BSD43_getdtablesize (__NR_BSD43 + 89) -#define __NR_BSD43_dup2 (__NR_BSD43 + 90) -#define __NR_BSD43_getdopt (__NR_BSD43 + 91) -#define __NR_BSD43_fcntl (__NR_BSD43 + 92) -#define __NR_BSD43_select (__NR_BSD43 + 93) -#define __NR_BSD43_setdopt (__NR_BSD43 + 94) -#define __NR_BSD43_fsync (__NR_BSD43 + 95) -#define __NR_BSD43_setpriority (__NR_BSD43 + 96) -#define __NR_BSD43_socket (__NR_BSD43 + 97) -#define __NR_BSD43_connect (__NR_BSD43 + 98) -#define __NR_BSD43_oldaccept (__NR_BSD43 + 99) -#define __NR_BSD43_getpriority (__NR_BSD43 + 100) -#define __NR_BSD43_send (__NR_BSD43 + 101) -#define __NR_BSD43_recv (__NR_BSD43 + 102) -#define __NR_BSD43_sigreturn (__NR_BSD43 + 103) -#define __NR_BSD43_bind (__NR_BSD43 + 104) -#define __NR_BSD43_setsockopt (__NR_BSD43 + 105) -#define __NR_BSD43_listen (__NR_BSD43 + 106) -#define __NR_BSD43_vtimes (__NR_BSD43 + 107) -#define __NR_BSD43_sigvec (__NR_BSD43 + 108) -#define __NR_BSD43_sigblock (__NR_BSD43 + 109) -#define __NR_BSD43_sigsetmask (__NR_BSD43 + 110) -#define __NR_BSD43_sigpause (__NR_BSD43 + 111) -#define __NR_BSD43_sigstack (__NR_BSD43 + 112) -#define __NR_BSD43_oldrecvmsg (__NR_BSD43 + 113) -#define __NR_BSD43_oldsendmsg (__NR_BSD43 + 114) -#define __NR_BSD43_vtrace (__NR_BSD43 + 115) -#define __NR_BSD43_gettimeofday (__NR_BSD43 + 116) -#define __NR_BSD43_getrusage (__NR_BSD43 + 117) -#define __NR_BSD43_getsockopt (__NR_BSD43 + 118) -#define __NR_BSD43_reserved4 (__NR_BSD43 + 119) -#define __NR_BSD43_readv (__NR_BSD43 + 120) -#define __NR_BSD43_writev (__NR_BSD43 + 121) -#define __NR_BSD43_settimeofday (__NR_BSD43 + 122) -#define __NR_BSD43_fchown (__NR_BSD43 + 123) -#define __NR_BSD43_fchmod (__NR_BSD43 + 124) -#define __NR_BSD43_oldrecvfrom (__NR_BSD43 + 125) -#define __NR_BSD43_setreuid (__NR_BSD43 + 126) -#define __NR_BSD43_setregid (__NR_BSD43 + 127) -#define __NR_BSD43_rename (__NR_BSD43 + 128) -#define __NR_BSD43_truncate (__NR_BSD43 + 129) -#define __NR_BSD43_ftruncate (__NR_BSD43 + 130) -#define __NR_BSD43_flock (__NR_BSD43 + 131) -#define __NR_BSD43_semsys (__NR_BSD43 + 132) -#define __NR_BSD43_sendto (__NR_BSD43 + 133) -#define __NR_BSD43_shutdown (__NR_BSD43 + 134) -#define __NR_BSD43_socketpair (__NR_BSD43 + 135) -#define __NR_BSD43_mkdir (__NR_BSD43 + 136) -#define __NR_BSD43_rmdir (__NR_BSD43 + 137) -#define __NR_BSD43_utimes (__NR_BSD43 + 138) -#define __NR_BSD43_sigcleanup (__NR_BSD43 + 139) -#define __NR_BSD43_adjtime (__NR_BSD43 + 140) -#define __NR_BSD43_oldgetpeername (__NR_BSD43 + 141) -#define __NR_BSD43_gethostid (__NR_BSD43 + 142) -#define __NR_BSD43_sethostid (__NR_BSD43 + 143) -#define __NR_BSD43_getrlimit (__NR_BSD43 + 144) -#define __NR_BSD43_setrlimit (__NR_BSD43 + 145) -#define __NR_BSD43_killpg (__NR_BSD43 + 146) -#define __NR_BSD43_shmsys (__NR_BSD43 + 147) -#define __NR_BSD43_quota (__NR_BSD43 + 148) -#define __NR_BSD43_qquota (__NR_BSD43 + 149) -#define __NR_BSD43_oldgetsockname (__NR_BSD43 + 150) -#define __NR_BSD43_sysmips (__NR_BSD43 + 151) -#define __NR_BSD43_cacheflush (__NR_BSD43 + 152) -#define __NR_BSD43_cachectl (__NR_BSD43 + 153) -#define __NR_BSD43_debug (__NR_BSD43 + 154) -#define __NR_BSD43_reserved5 (__NR_BSD43 + 155) -#define __NR_BSD43_reserved6 (__NR_BSD43 + 156) -#define __NR_BSD43_nfs_mount (__NR_BSD43 + 157) -#define __NR_BSD43_nfs_svc (__NR_BSD43 + 158) -#define __NR_BSD43_getdirentries (__NR_BSD43 + 159) -#define __NR_BSD43_statfs (__NR_BSD43 + 160) -#define __NR_BSD43_fstatfs (__NR_BSD43 + 161) -#define __NR_BSD43_unmount (__NR_BSD43 + 162) -#define __NR_BSD43_async_daemon (__NR_BSD43 + 163) -#define __NR_BSD43_nfs_getfh (__NR_BSD43 + 164) -#define __NR_BSD43_getdomainname (__NR_BSD43 + 165) -#define __NR_BSD43_setdomainname (__NR_BSD43 + 166) -#define __NR_BSD43_pcfs_mount (__NR_BSD43 + 167) -#define __NR_BSD43_quotactl (__NR_BSD43 + 168) -#define __NR_BSD43_oldexportfs (__NR_BSD43 + 169) -#define __NR_BSD43_smount (__NR_BSD43 + 170) -#define __NR_BSD43_mipshwconf (__NR_BSD43 + 171) -#define __NR_BSD43_exportfs (__NR_BSD43 + 172) -#define __NR_BSD43_nfsfh_open (__NR_BSD43 + 173) -#define __NR_BSD43_libattach (__NR_BSD43 + 174) -#define __NR_BSD43_libdetach (__NR_BSD43 + 175) -#define __NR_BSD43_accept (__NR_BSD43 + 176) -#define __NR_BSD43_reserved7 (__NR_BSD43 + 177) -#define __NR_BSD43_reserved8 (__NR_BSD43 + 178) -#define __NR_BSD43_recvmsg (__NR_BSD43 + 179) -#define __NR_BSD43_recvfrom (__NR_BSD43 + 180) -#define __NR_BSD43_sendmsg (__NR_BSD43 + 181) -#define __NR_BSD43_getpeername (__NR_BSD43 + 182) -#define __NR_BSD43_getsockname (__NR_BSD43 + 183) -#define __NR_BSD43_aread (__NR_BSD43 + 184) -#define __NR_BSD43_awrite (__NR_BSD43 + 185) -#define __NR_BSD43_listio (__NR_BSD43 + 186) -#define __NR_BSD43_acancel (__NR_BSD43 + 187) -#define __NR_BSD43_astatus (__NR_BSD43 + 188) -#define __NR_BSD43_await (__NR_BSD43 + 189) -#define __NR_BSD43_areadv (__NR_BSD43 + 190) -#define __NR_BSD43_awritev (__NR_BSD43 + 191) - -/* - * POSIX syscalls are in the range from 3000 to 3999 - */ -#define __NR_POSIX 3000 -#define __NR_POSIX_syscall (__NR_POSIX + 0) -#define __NR_POSIX_exit (__NR_POSIX + 1) -#define __NR_POSIX_fork (__NR_POSIX + 2) -#define __NR_POSIX_read (__NR_POSIX + 3) -#define __NR_POSIX_write (__NR_POSIX + 4) -#define __NR_POSIX_open (__NR_POSIX + 5) -#define __NR_POSIX_close (__NR_POSIX + 6) -#define __NR_POSIX_wait (__NR_POSIX + 7) -#define __NR_POSIX_creat (__NR_POSIX + 8) -#define __NR_POSIX_link (__NR_POSIX + 9) -#define __NR_POSIX_unlink (__NR_POSIX + 10) -#define __NR_POSIX_exec (__NR_POSIX + 11) -#define __NR_POSIX_chdir (__NR_POSIX + 12) -#define __NR_POSIX_gtime (__NR_POSIX + 13) -#define __NR_POSIX_mknod (__NR_POSIX + 14) -#define __NR_POSIX_chmod (__NR_POSIX + 15) -#define __NR_POSIX_chown (__NR_POSIX + 16) -#define __NR_POSIX_sbreak (__NR_POSIX + 17) -#define __NR_POSIX_stat (__NR_POSIX + 18) -#define __NR_POSIX_lseek (__NR_POSIX + 19) -#define __NR_POSIX_getpid (__NR_POSIX + 20) -#define __NR_POSIX_mount (__NR_POSIX + 21) -#define __NR_POSIX_umount (__NR_POSIX + 22) -#define __NR_POSIX_setuid (__NR_POSIX + 23) -#define __NR_POSIX_getuid (__NR_POSIX + 24) -#define __NR_POSIX_stime (__NR_POSIX + 25) -#define __NR_POSIX_ptrace (__NR_POSIX + 26) -#define __NR_POSIX_alarm (__NR_POSIX + 27) -#define __NR_POSIX_fstat (__NR_POSIX + 28) -#define __NR_POSIX_pause (__NR_POSIX + 29) -#define __NR_POSIX_utime (__NR_POSIX + 30) -#define __NR_POSIX_stty (__NR_POSIX + 31) -#define __NR_POSIX_gtty (__NR_POSIX + 32) -#define __NR_POSIX_access (__NR_POSIX + 33) -#define __NR_POSIX_nice (__NR_POSIX + 34) -#define __NR_POSIX_statfs (__NR_POSIX + 35) -#define __NR_POSIX_sync (__NR_POSIX + 36) -#define __NR_POSIX_kill (__NR_POSIX + 37) -#define __NR_POSIX_fstatfs (__NR_POSIX + 38) -#define __NR_POSIX_getpgrp (__NR_POSIX + 39) -#define __NR_POSIX_syssgi (__NR_POSIX + 40) -#define __NR_POSIX_dup (__NR_POSIX + 41) -#define __NR_POSIX_pipe (__NR_POSIX + 42) -#define __NR_POSIX_times (__NR_POSIX + 43) -#define __NR_POSIX_profil (__NR_POSIX + 44) -#define __NR_POSIX_lock (__NR_POSIX + 45) -#define __NR_POSIX_setgid (__NR_POSIX + 46) -#define __NR_POSIX_getgid (__NR_POSIX + 47) -#define __NR_POSIX_sig (__NR_POSIX + 48) -#define __NR_POSIX_msgsys (__NR_POSIX + 49) -#define __NR_POSIX_sysmips (__NR_POSIX + 50) -#define __NR_POSIX_sysacct (__NR_POSIX + 51) -#define __NR_POSIX_shmsys (__NR_POSIX + 52) -#define __NR_POSIX_semsys (__NR_POSIX + 53) -#define __NR_POSIX_ioctl (__NR_POSIX + 54) -#define __NR_POSIX_uadmin (__NR_POSIX + 55) -#define __NR_POSIX_exch (__NR_POSIX + 56) -#define __NR_POSIX_utssys (__NR_POSIX + 57) -#define __NR_POSIX_USG_reserved1 (__NR_POSIX + 58) -#define __NR_POSIX_exece (__NR_POSIX + 59) -#define __NR_POSIX_umask (__NR_POSIX + 60) -#define __NR_POSIX_chroot (__NR_POSIX + 61) -#define __NR_POSIX_fcntl (__NR_POSIX + 62) -#define __NR_POSIX_ulimit (__NR_POSIX + 63) -#define __NR_POSIX_SAFARI4_reserved1 (__NR_POSIX + 64) -#define __NR_POSIX_SAFARI4_reserved2 (__NR_POSIX + 65) -#define __NR_POSIX_SAFARI4_reserved3 (__NR_POSIX + 66) -#define __NR_POSIX_SAFARI4_reserved4 (__NR_POSIX + 67) -#define __NR_POSIX_SAFARI4_reserved5 (__NR_POSIX + 68) -#define __NR_POSIX_SAFARI4_reserved6 (__NR_POSIX + 69) -#define __NR_POSIX_advfs (__NR_POSIX + 70) -#define __NR_POSIX_unadvfs (__NR_POSIX + 71) -#define __NR_POSIX_rmount (__NR_POSIX + 72) -#define __NR_POSIX_rumount (__NR_POSIX + 73) -#define __NR_POSIX_rfstart (__NR_POSIX + 74) -#define __NR_POSIX_reserved1 (__NR_POSIX + 75) -#define __NR_POSIX_rdebug (__NR_POSIX + 76) -#define __NR_POSIX_rfstop (__NR_POSIX + 77) -#define __NR_POSIX_rfsys (__NR_POSIX + 78) -#define __NR_POSIX_rmdir (__NR_POSIX + 79) -#define __NR_POSIX_mkdir (__NR_POSIX + 80) -#define __NR_POSIX_getdents (__NR_POSIX + 81) -#define __NR_POSIX_sginap (__NR_POSIX + 82) -#define __NR_POSIX_sgikopt (__NR_POSIX + 83) -#define __NR_POSIX_sysfs (__NR_POSIX + 84) -#define __NR_POSIX_getmsg (__NR_POSIX + 85) -#define __NR_POSIX_putmsg (__NR_POSIX + 86) -#define __NR_POSIX_poll (__NR_POSIX + 87) -#define __NR_POSIX_sigreturn (__NR_POSIX + 88) -#define __NR_POSIX_accept (__NR_POSIX + 89) -#define __NR_POSIX_bind (__NR_POSIX + 90) -#define __NR_POSIX_connect (__NR_POSIX + 91) -#define __NR_POSIX_gethostid (__NR_POSIX + 92) -#define __NR_POSIX_getpeername (__NR_POSIX + 93) -#define __NR_POSIX_getsockname (__NR_POSIX + 94) -#define __NR_POSIX_getsockopt (__NR_POSIX + 95) -#define __NR_POSIX_listen (__NR_POSIX + 96) -#define __NR_POSIX_recv (__NR_POSIX + 97) -#define __NR_POSIX_recvfrom (__NR_POSIX + 98) -#define __NR_POSIX_recvmsg (__NR_POSIX + 99) -#define __NR_POSIX_select (__NR_POSIX + 100) -#define __NR_POSIX_send (__NR_POSIX + 101) -#define __NR_POSIX_sendmsg (__NR_POSIX + 102) -#define __NR_POSIX_sendto (__NR_POSIX + 103) -#define __NR_POSIX_sethostid (__NR_POSIX + 104) -#define __NR_POSIX_setsockopt (__NR_POSIX + 105) -#define __NR_POSIX_shutdown (__NR_POSIX + 106) -#define __NR_POSIX_socket (__NR_POSIX + 107) -#define __NR_POSIX_gethostname (__NR_POSIX + 108) -#define __NR_POSIX_sethostname (__NR_POSIX + 109) -#define __NR_POSIX_getdomainname (__NR_POSIX + 110) -#define __NR_POSIX_setdomainname (__NR_POSIX + 111) -#define __NR_POSIX_truncate (__NR_POSIX + 112) -#define __NR_POSIX_ftruncate (__NR_POSIX + 113) -#define __NR_POSIX_rename (__NR_POSIX + 114) -#define __NR_POSIX_symlink (__NR_POSIX + 115) -#define __NR_POSIX_readlink (__NR_POSIX + 116) -#define __NR_POSIX_lstat (__NR_POSIX + 117) -#define __NR_POSIX_nfs_mount (__NR_POSIX + 118) -#define __NR_POSIX_nfs_svc (__NR_POSIX + 119) -#define __NR_POSIX_nfs_getfh (__NR_POSIX + 120) -#define __NR_POSIX_async_daemon (__NR_POSIX + 121) -#define __NR_POSIX_exportfs (__NR_POSIX + 122) -#define __NR_POSIX_SGI_setregid (__NR_POSIX + 123) -#define __NR_POSIX_SGI_setreuid (__NR_POSIX + 124) -#define __NR_POSIX_getitimer (__NR_POSIX + 125) -#define __NR_POSIX_setitimer (__NR_POSIX + 126) -#define __NR_POSIX_adjtime (__NR_POSIX + 127) -#define __NR_POSIX_SGI_bsdgettime (__NR_POSIX + 128) -#define __NR_POSIX_SGI_sproc (__NR_POSIX + 129) -#define __NR_POSIX_SGI_prctl (__NR_POSIX + 130) -#define __NR_POSIX_SGI_blkproc (__NR_POSIX + 131) -#define __NR_POSIX_SGI_reserved1 (__NR_POSIX + 132) -#define __NR_POSIX_SGI_sgigsc (__NR_POSIX + 133) -#define __NR_POSIX_SGI_mmap (__NR_POSIX + 134) -#define __NR_POSIX_SGI_munmap (__NR_POSIX + 135) -#define __NR_POSIX_SGI_mprotect (__NR_POSIX + 136) -#define __NR_POSIX_SGI_msync (__NR_POSIX + 137) -#define __NR_POSIX_SGI_madvise (__NR_POSIX + 138) -#define __NR_POSIX_SGI_mpin (__NR_POSIX + 139) -#define __NR_POSIX_SGI_getpagesize (__NR_POSIX + 140) -#define __NR_POSIX_SGI_libattach (__NR_POSIX + 141) -#define __NR_POSIX_SGI_libdetach (__NR_POSIX + 142) -#define __NR_POSIX_SGI_getpgrp (__NR_POSIX + 143) -#define __NR_POSIX_SGI_setpgrp (__NR_POSIX + 144) -#define __NR_POSIX_SGI_reserved2 (__NR_POSIX + 145) -#define __NR_POSIX_SGI_reserved3 (__NR_POSIX + 146) -#define __NR_POSIX_SGI_reserved4 (__NR_POSIX + 147) -#define __NR_POSIX_SGI_reserved5 (__NR_POSIX + 148) -#define __NR_POSIX_SGI_reserved6 (__NR_POSIX + 149) -#define __NR_POSIX_cacheflush (__NR_POSIX + 150) -#define __NR_POSIX_cachectl (__NR_POSIX + 151) -#define __NR_POSIX_fchown (__NR_POSIX + 152) -#define __NR_POSIX_fchmod (__NR_POSIX + 153) -#define __NR_POSIX_wait3 (__NR_POSIX + 154) -#define __NR_POSIX_mmap (__NR_POSIX + 155) -#define __NR_POSIX_munmap (__NR_POSIX + 156) -#define __NR_POSIX_madvise (__NR_POSIX + 157) -#define __NR_POSIX_BSD_getpagesize (__NR_POSIX + 158) -#define __NR_POSIX_setreuid (__NR_POSIX + 159) -#define __NR_POSIX_setregid (__NR_POSIX + 160) -#define __NR_POSIX_setpgid (__NR_POSIX + 161) -#define __NR_POSIX_getgroups (__NR_POSIX + 162) -#define __NR_POSIX_setgroups (__NR_POSIX + 163) -#define __NR_POSIX_gettimeofday (__NR_POSIX + 164) -#define __NR_POSIX_getrusage (__NR_POSIX + 165) -#define __NR_POSIX_getrlimit (__NR_POSIX + 166) -#define __NR_POSIX_setrlimit (__NR_POSIX + 167) -#define __NR_POSIX_waitpid (__NR_POSIX + 168) -#define __NR_POSIX_dup2 (__NR_POSIX + 169) -#define __NR_POSIX_reserved2 (__NR_POSIX + 170) -#define __NR_POSIX_reserved3 (__NR_POSIX + 171) -#define __NR_POSIX_reserved4 (__NR_POSIX + 172) -#define __NR_POSIX_reserved5 (__NR_POSIX + 173) -#define __NR_POSIX_reserved6 (__NR_POSIX + 174) -#define __NR_POSIX_reserved7 (__NR_POSIX + 175) -#define __NR_POSIX_reserved8 (__NR_POSIX + 176) -#define __NR_POSIX_reserved9 (__NR_POSIX + 177) -#define __NR_POSIX_reserved10 (__NR_POSIX + 178) -#define __NR_POSIX_reserved11 (__NR_POSIX + 179) -#define __NR_POSIX_reserved12 (__NR_POSIX + 180) -#define __NR_POSIX_reserved13 (__NR_POSIX + 181) -#define __NR_POSIX_reserved14 (__NR_POSIX + 182) -#define __NR_POSIX_reserved15 (__NR_POSIX + 183) -#define __NR_POSIX_reserved16 (__NR_POSIX + 184) -#define __NR_POSIX_reserved17 (__NR_POSIX + 185) -#define __NR_POSIX_reserved18 (__NR_POSIX + 186) -#define __NR_POSIX_reserved19 (__NR_POSIX + 187) -#define __NR_POSIX_reserved20 (__NR_POSIX + 188) -#define __NR_POSIX_reserved21 (__NR_POSIX + 189) -#define __NR_POSIX_reserved22 (__NR_POSIX + 190) -#define __NR_POSIX_reserved23 (__NR_POSIX + 191) -#define __NR_POSIX_reserved24 (__NR_POSIX + 192) -#define __NR_POSIX_reserved25 (__NR_POSIX + 193) -#define __NR_POSIX_reserved26 (__NR_POSIX + 194) -#define __NR_POSIX_reserved27 (__NR_POSIX + 195) -#define __NR_POSIX_reserved28 (__NR_POSIX + 196) -#define __NR_POSIX_reserved29 (__NR_POSIX + 197) -#define __NR_POSIX_reserved30 (__NR_POSIX + 198) -#define __NR_POSIX_reserved31 (__NR_POSIX + 199) -#define __NR_POSIX_reserved32 (__NR_POSIX + 200) -#define __NR_POSIX_reserved33 (__NR_POSIX + 201) -#define __NR_POSIX_reserved34 (__NR_POSIX + 202) -#define __NR_POSIX_reserved35 (__NR_POSIX + 203) -#define __NR_POSIX_reserved36 (__NR_POSIX + 204) -#define __NR_POSIX_reserved37 (__NR_POSIX + 205) -#define __NR_POSIX_reserved38 (__NR_POSIX + 206) -#define __NR_POSIX_reserved39 (__NR_POSIX + 207) -#define __NR_POSIX_reserved40 (__NR_POSIX + 208) -#define __NR_POSIX_reserved41 (__NR_POSIX + 209) -#define __NR_POSIX_reserved42 (__NR_POSIX + 210) -#define __NR_POSIX_reserved43 (__NR_POSIX + 211) -#define __NR_POSIX_reserved44 (__NR_POSIX + 212) -#define __NR_POSIX_reserved45 (__NR_POSIX + 213) -#define __NR_POSIX_reserved46 (__NR_POSIX + 214) -#define __NR_POSIX_reserved47 (__NR_POSIX + 215) -#define __NR_POSIX_reserved48 (__NR_POSIX + 216) -#define __NR_POSIX_reserved49 (__NR_POSIX + 217) -#define __NR_POSIX_reserved50 (__NR_POSIX + 218) -#define __NR_POSIX_reserved51 (__NR_POSIX + 219) -#define __NR_POSIX_reserved52 (__NR_POSIX + 220) -#define __NR_POSIX_reserved53 (__NR_POSIX + 221) -#define __NR_POSIX_reserved54 (__NR_POSIX + 222) -#define __NR_POSIX_reserved55 (__NR_POSIX + 223) -#define __NR_POSIX_reserved56 (__NR_POSIX + 224) -#define __NR_POSIX_reserved57 (__NR_POSIX + 225) -#define __NR_POSIX_reserved58 (__NR_POSIX + 226) -#define __NR_POSIX_reserved59 (__NR_POSIX + 227) -#define __NR_POSIX_reserved60 (__NR_POSIX + 228) -#define __NR_POSIX_reserved61 (__NR_POSIX + 229) -#define __NR_POSIX_reserved62 (__NR_POSIX + 230) -#define __NR_POSIX_reserved63 (__NR_POSIX + 231) -#define __NR_POSIX_reserved64 (__NR_POSIX + 232) -#define __NR_POSIX_reserved65 (__NR_POSIX + 233) -#define __NR_POSIX_reserved66 (__NR_POSIX + 234) -#define __NR_POSIX_reserved67 (__NR_POSIX + 235) -#define __NR_POSIX_reserved68 (__NR_POSIX + 236) -#define __NR_POSIX_reserved69 (__NR_POSIX + 237) -#define __NR_POSIX_reserved70 (__NR_POSIX + 238) -#define __NR_POSIX_reserved71 (__NR_POSIX + 239) -#define __NR_POSIX_reserved72 (__NR_POSIX + 240) -#define __NR_POSIX_reserved73 (__NR_POSIX + 241) -#define __NR_POSIX_reserved74 (__NR_POSIX + 242) -#define __NR_POSIX_reserved75 (__NR_POSIX + 243) -#define __NR_POSIX_reserved76 (__NR_POSIX + 244) -#define __NR_POSIX_reserved77 (__NR_POSIX + 245) -#define __NR_POSIX_reserved78 (__NR_POSIX + 246) -#define __NR_POSIX_reserved79 (__NR_POSIX + 247) -#define __NR_POSIX_reserved80 (__NR_POSIX + 248) -#define __NR_POSIX_reserved81 (__NR_POSIX + 249) -#define __NR_POSIX_reserved82 (__NR_POSIX + 250) -#define __NR_POSIX_reserved83 (__NR_POSIX + 251) -#define __NR_POSIX_reserved84 (__NR_POSIX + 252) -#define __NR_POSIX_reserved85 (__NR_POSIX + 253) -#define __NR_POSIX_reserved86 (__NR_POSIX + 254) -#define __NR_POSIX_reserved87 (__NR_POSIX + 255) -#define __NR_POSIX_reserved88 (__NR_POSIX + 256) -#define __NR_POSIX_reserved89 (__NR_POSIX + 257) -#define __NR_POSIX_reserved90 (__NR_POSIX + 258) -#define __NR_POSIX_reserved91 (__NR_POSIX + 259) -#define __NR_POSIX_netboot (__NR_POSIX + 260) -#define __NR_POSIX_netunboot (__NR_POSIX + 261) -#define __NR_POSIX_rdump (__NR_POSIX + 262) -#define __NR_POSIX_setsid (__NR_POSIX + 263) -#define __NR_POSIX_getmaxsig (__NR_POSIX + 264) -#define __NR_POSIX_sigpending (__NR_POSIX + 265) -#define __NR_POSIX_sigprocmask (__NR_POSIX + 266) -#define __NR_POSIX_sigsuspend (__NR_POSIX + 267) -#define __NR_POSIX_sigaction (__NR_POSIX + 268) -#define __NR_POSIX_MIPS_reserved1 (__NR_POSIX + 269) -#define __NR_POSIX_MIPS_reserved2 (__NR_POSIX + 270) -#define __NR_POSIX_MIPS_reserved3 (__NR_POSIX + 271) -#define __NR_POSIX_MIPS_reserved4 (__NR_POSIX + 272) -#define __NR_POSIX_MIPS_reserved5 (__NR_POSIX + 273) -#define __NR_POSIX_MIPS_reserved6 (__NR_POSIX + 274) -#define __NR_POSIX_MIPS_reserved7 (__NR_POSIX + 275) -#define __NR_POSIX_MIPS_reserved8 (__NR_POSIX + 276) -#define __NR_POSIX_MIPS_reserved9 (__NR_POSIX + 277) -#define __NR_POSIX_MIPS_reserved10 (__NR_POSIX + 278) -#define __NR_POSIX_MIPS_reserved11 (__NR_POSIX + 279) -#define __NR_POSIX_TANDEM_reserved1 (__NR_POSIX + 280) -#define __NR_POSIX_TANDEM_reserved2 (__NR_POSIX + 281) -#define __NR_POSIX_TANDEM_reserved3 (__NR_POSIX + 282) -#define __NR_POSIX_TANDEM_reserved4 (__NR_POSIX + 283) -#define __NR_POSIX_TANDEM_reserved5 (__NR_POSIX + 284) -#define __NR_POSIX_TANDEM_reserved6 (__NR_POSIX + 285) -#define __NR_POSIX_TANDEM_reserved7 (__NR_POSIX + 286) -#define __NR_POSIX_TANDEM_reserved8 (__NR_POSIX + 287) -#define __NR_POSIX_TANDEM_reserved9 (__NR_POSIX + 288) -#define __NR_POSIX_TANDEM_reserved10 (__NR_POSIX + 289) -#define __NR_POSIX_TANDEM_reserved11 (__NR_POSIX + 290) -#define __NR_POSIX_TANDEM_reserved12 (__NR_POSIX + 291) -#define __NR_POSIX_TANDEM_reserved13 (__NR_POSIX + 292) -#define __NR_POSIX_TANDEM_reserved14 (__NR_POSIX + 293) -#define __NR_POSIX_TANDEM_reserved15 (__NR_POSIX + 294) -#define __NR_POSIX_TANDEM_reserved16 (__NR_POSIX + 295) -#define __NR_POSIX_TANDEM_reserved17 (__NR_POSIX + 296) -#define __NR_POSIX_TANDEM_reserved18 (__NR_POSIX + 297) -#define __NR_POSIX_TANDEM_reserved19 (__NR_POSIX + 298) -#define __NR_POSIX_TANDEM_reserved20 (__NR_POSIX + 299) -#define __NR_POSIX_SGI_reserved7 (__NR_POSIX + 300) -#define __NR_POSIX_SGI_reserved8 (__NR_POSIX + 301) -#define __NR_POSIX_SGI_reserved9 (__NR_POSIX + 302) -#define __NR_POSIX_SGI_reserved10 (__NR_POSIX + 303) -#define __NR_POSIX_SGI_reserved11 (__NR_POSIX + 304) -#define __NR_POSIX_SGI_reserved12 (__NR_POSIX + 305) -#define __NR_POSIX_SGI_reserved13 (__NR_POSIX + 306) -#define __NR_POSIX_SGI_reserved14 (__NR_POSIX + 307) -#define __NR_POSIX_SGI_reserved15 (__NR_POSIX + 308) -#define __NR_POSIX_SGI_reserved16 (__NR_POSIX + 309) -#define __NR_POSIX_SGI_reserved17 (__NR_POSIX + 310) -#define __NR_POSIX_SGI_reserved18 (__NR_POSIX + 311) -#define __NR_POSIX_SGI_reserved19 (__NR_POSIX + 312) -#define __NR_POSIX_SGI_reserved20 (__NR_POSIX + 313) -#define __NR_POSIX_SGI_reserved21 (__NR_POSIX + 314) -#define __NR_POSIX_SGI_reserved22 (__NR_POSIX + 315) -#define __NR_POSIX_SGI_reserved23 (__NR_POSIX + 316) -#define __NR_POSIX_SGI_reserved24 (__NR_POSIX + 317) -#define __NR_POSIX_SGI_reserved25 (__NR_POSIX + 318) -#define __NR_POSIX_SGI_reserved26 (__NR_POSIX + 319) - -#endif /* _ASM_RISCOS_SYSCALL_H */ _ From frederic.temporelli@laposte.net Sun Mar 6 17:23:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 17:23:21 +0000 (GMT) Received: from mailfe07.swip.net ([IPv6:::ffff:212.247.154.193]:42978 "EHLO swip.net") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 17:23:07 +0000 X-T2-Posting-ID: g63wq726D5fsXb2UbU6LU0KOXzHnTHjCzHZ35sC2MDs= Received: from [83.177.235.13] (HELO [192.168.0.32]) by mailfe07.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 116470614 for linux-mips@linux-mips.org; Sun, 06 Mar 2005 18:23:00 +0100 Message-ID: <422B3C74.9090706@laposte.net> Date: Sun, 06 Mar 2005 18:23:00 +0100 From: Frederic TEMPORELLI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: SGI IP32 and 2.6.11 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: frederic.temporelli@laposte.net Precedence: bulk X-list: linux-mips Hello, I've just been able to start 2.6.11 from my own compilation on IP32. Can I have some help about following problems/comments ? 1/ It was really difficult because kernel was falling in breakpoint call (BUG macro) in free_bootmem_core. => I've successfully try to comment this BUG macro in free_bootmem_core (bootmem.c) Of course, I'm thinking this is really sad... but I've a really poor knowledge in kernel development... may someone can explain how to solve such issue in a better way ? This breakpoint was boring me since 2.6.10... 2/ There's also a problem with ip32-memory.c, which isn't able to detect 64MB dimm. Yet, not enough knowledge for processing bankctl (prom_meminit) in the nice way for detecting 64MB dimms... (All memory slots are used on my O2: slots 1 to 6 with 32MB dimms and slots 7 & 8 with 64MB dimms) . Best regards Frederic TEMPORELLI From ilya@total-knowledge.com Sun Mar 6 19:14:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 19:14:21 +0000 (GMT) Received: from alpha.total-knowledge.com ([IPv6:::ffff:205.217.158.170]:2796 "EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 19:14:06 +0000 Received: (qmail 11475 invoked from network); 6 Mar 2005 00:49:26 -0800 Received: from c-24-6-216-150.client.comcast.net (HELO ?192.168.0.238?) (24.6.216.150) by alpha.total-knowledge.com with SMTP; 6 Mar 2005 00:49:26 -0800 Message-ID: <422B5676.7090207@total-knowledge.com> Date: Sun, 06 Mar 2005 11:13:58 -0800 From: "Ilya A. Volynets-Evenbakh" Organization: Total Knowledge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frederic TEMPORELLI CC: linux-mips@linux-mips.org Subject: Re: SGI IP32 and 2.6.11 References: <422B3C74.9090706@laposte.net> In-Reply-To: <422B3C74.9090706@laposte.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@total-knowledge.com Precedence: bulk X-list: linux-mips There is no such thing as 64M DIMM for O2. Put correct memory into your machine and both of these problems will be solved. Frederic TEMPORELLI wrote: > Hello, > > I've just been able to start 2.6.11 from my own compilation on IP32. > > Can I have some help about following problems/comments ? > > 1/ It was really difficult because kernel was falling in breakpoint > call (BUG macro) in free_bootmem_core. > => I've successfully try to comment this BUG macro in > free_bootmem_core (bootmem.c) > Of course, I'm thinking this is really sad... but I've a really poor > knowledge in kernel development... > may someone can explain how to solve such issue in a better way ? > This breakpoint was boring me since 2.6.10... > > 2/ There's also a problem with ip32-memory.c, which isn't able to > detect 64MB dimm. > Yet, not enough knowledge for processing bankctl (prom_meminit) in the > nice way for detecting 64MB dimms... > (All memory slots are used on my O2: slots 1 to 6 with 32MB dimms and > slots 7 & 8 with 64MB dimms) . > > Best regards > > Frederic TEMPORELLI > > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From ftemporelli@astek.fr Sun Mar 6 20:01:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Mar 2005 20:01:50 +0000 (GMT) Received: from mailfe04.swip.net ([IPv6:::ffff:212.247.154.97]:2298 "EHLO swip.net") by linux-mips.org with ESMTP id ; Sun, 6 Mar 2005 20:01:35 +0000 X-T2-Posting-ID: g63wq726D5fsXb2UbU6LU0KOXzHnTHjCzHZ35sC2MDs= Received: from [83.177.235.13] (HELO [192.168.0.32]) by mailfe04.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 313604262; Sun, 06 Mar 2005 21:01:29 +0100 Message-ID: <422B6192.2080801@astek.fr> Date: Sun, 06 Mar 2005 21:01:22 +0100 From: Frederic TEMPORELLI - astek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en MIME-Version: 1.0 To: "Ilya A. Volynets-Evenbakh" CC: linux-mips@linux-mips.org Subject: Re: SGI IP32 and 2.6.11 References: <422B3C74.9090706@laposte.net> <422B5676.7090207@total-knowledge.com> In-Reply-To: <422B5676.7090207@total-knowledge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ftemporelli@astek.fr Precedence: bulk X-list: linux-mips Hello Ilya, yep, following my mail I just try to rebuild the kernel with more drivers and reboot on this kernel failed. Now, same kernel but without the 64MB dimms, boot on this kernel is working fine. thanks !!! for information, 64 MB dimms are "transtec" with s/n DRA0SM1 (nothing about them on google :-( ). These dimms where installed on an other IP32 (I just add them in my O2) and hinv was reporting 320MB with all dimms installed (6*32MB + these 2 dimms) Best regards Frederic Ilya A. Volynets-Evenbakh a écrit : > There is no such thing as 64M DIMM for O2. Put correct memory into > your machine and > both of these problems will be solved. > > Frederic TEMPORELLI wrote: > >> Hello, >> >> I've just been able to start 2.6.11 from my own compilation on IP32. >> >> Can I have some help about following problems/comments ? >> >> 1/ It was really difficult because kernel was falling in breakpoint >> call (BUG macro) in free_bootmem_core. >> => I've successfully try to comment this BUG macro in >> free_bootmem_core (bootmem.c) >> Of course, I'm thinking this is really sad... but I've a really poor >> knowledge in kernel development... >> may someone can explain how to solve such issue in a better way ? >> This breakpoint was boring me since 2.6.10... >> >> 2/ There's also a problem with ip32-memory.c, which isn't able to >> detect 64MB dimm. >> Yet, not enough knowledge for processing bankctl (prom_meminit) in >> the nice way for detecting 64MB dimms... >> (All memory slots are used on my O2: slots 1 to 6 with 32MB dimms and >> slots 7 & 8 with 64MB dimms) . >> >> Best regards >> >> Frederic TEMPORELLI >> >> >> > > From Rishabh@soc-soft.com Mon Mar 7 12:20:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 12:20:54 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:3597 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Mon, 7 Mar 2005 12:20:35 +0000 Received: from soc-mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Mon, 07 Mar 2005 17:52:15 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52310.4C19A488" Subject: How /sbin/init is executed X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 7 Mar 2005 17:52:15 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C5F282A@soc-mail.soc-soft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: How /sbin/init is executed Thread-Index: AcUjEEucnsXfHjuVQ/67k31nFnx8OQ== From: To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rishabh@soc-soft.com Precedence: bulk X-list: linux-mips Content-Length: 2388 Lines: 70 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52310.4C19A488 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am working on HIGHMEM implementation on Monta Vista Linux 3.1. I am able to boot the kernel till "/sbin/init".=0D I am getting stuck with How /sbin/init is fetched and executed from Target ROOT Dir.=0D Is it that a part of /sbin/init file is fetched and executed and then the other part of the file is fetched? If I want to debug the progress of /sbin/init execution then how can I proceed in this direction? Rishabh Kumar Goel Software Engineer =0D SoCrates Software India Pvt. Ltd. a TOSHIBA Group Company #10, Industrial Layout, Prestige Atlanta, III Block, Koramangala, Bangalore - 560034 =0D Ph. 080-51101669 The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If= you are not the intended recipient, please notify the sender and delete the message= along with any annexure. You should not disclose, copy or otherwise use the= information contained in the message or any annexure. Any views expressed in this e-mail are= those of the individual sender except where the sender specifically states them to be= the views of SoCrates Software India Pvt Ltd., Bangalore. ------_=_NextPart_001_01C52310.4C19A488 Content-Type: text/x-vcard; name="Rishabh Kumar Goel.vcf" Content-Transfer-Encoding: base64 Content-Description: Rishabh Kumar Goel.vcf Content-Disposition: attachment; filename="Rishabh Kumar Goel.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkdvZWw7UmlzaGFiaCBLdW1hcg0KRk46UmlzaGFi aCBLdW1hciBHb2VsDQpPUkc6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0IEx0ZC47T1MgJiBE RA0KVElUTEU6U0UNClRFTDtXT1JLO1ZPSUNFOjUxMTAxNjY5ICAgIEV4dDoyNjY5DQpBRFI7V09S SztFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOjtTb2NyYXRlcyBTb2Z0d2FyZSBJbmRpYSBQdnQu IEx0ZC47MTAgQnJpZGUgU3RyZWV0LCA9MEQ9MEFMYW5nZm9yZCBUb3duO0Jhbmc9DQphbG9yZTtL YXJuYXRha2E7NTYwMDI1O0lORElBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFC TEU6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0LiBMdGQuPTBEPTBBMTAgQnJpZGUgU3RyZWV0 LCA9MEQ9MEFMYW5nZm9yZCBUb3duPQ0KPTBEPTBBQmFuZ2Fsb3JlLCBLYXJuYXRha2EgNTYwMDI1 PTBEPTBBSU5ESUENCkVNQUlMO1BSRUY7SU5URVJORVQ6UmlzaGFiaEBzb2Mtc29mdC5jb20NClJF VjoyMDA1MDIxN1QwNjA4NDJaDQpFTkQ6VkNBUkQNCg== ------_=_NextPart_001_01C52310.4C19A488-- From yuasa@hh.iij4u.or.jp Mon Mar 7 16:28:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 16:28:42 +0000 (GMT) Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:34533 "EHLO mo01.iij4u.or.jp") by linux-mips.org with ESMTP id ; Mon, 7 Mar 2005 16:28:22 +0000 Received: MO(mo01)id j27GSICl028734; Tue, 8 Mar 2005 01:28:18 +0900 (JST) Received: MDO(mdo01) id j27GSHFH028992; Tue, 8 Mar 2005 01:28:18 +0900 (JST) Received: 4UMRO01 id j27GSG8B007569; Tue, 8 Mar 2005 01:28:17 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Tue, 8 Mar 2005 01:28:15 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH 2.6] update PCI code for VR41xx Message-Id: <20050308012815.0a02095e.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Content-Length: 16770 Lines: 542 Hello Ralf, This patch updates PCI code for VR41xx. Please apply this patch to v2.6. Yoichi Signed-off-by: Yoichi Yuasa diff -urN -X dontdiff a-orig/arch/mips/pci/ops-vr41xx.c a/arch/mips/pci/ops-vr41xx.c --- a-orig/arch/mips/pci/ops-vr41xx.c Thu May 27 04:31:41 2004 +++ a/arch/mips/pci/ops-vr41xx.c Mon Feb 21 01:06:15 2005 @@ -3,7 +3,7 @@ * * Copyright (C) 2001-2003 MontaVista Software Inc. * Author: Yoichi Yuasa - * Copyright (C) 2004 Yoichi Yuasa + * Copyright (C) 2004-2005 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -29,8 +29,8 @@ #include -#define PCICONFDREG KSEG1ADDR(0x0f000c14) -#define PCICONFAREG KSEG1ADDR(0x0f000c18) +#define PCICONFDREG (void __iomem *)KSEG1ADDR(0x0f000c14) +#define PCICONFAREG (void __iomem *)KSEG1ADDR(0x0f000c18) static inline int set_pci_configuration_address(unsigned char number, unsigned int devfn, int where) diff -urN -X dontdiff a-orig/arch/mips/pci/pci-vr41xx.c a/arch/mips/pci/pci-vr41xx.c --- a-orig/arch/mips/pci/pci-vr41xx.c Sun Jan 16 22:34:31 2005 +++ a/arch/mips/pci/pci-vr41xx.c Mon Feb 21 01:06:15 2005 @@ -3,8 +3,8 @@ * * Copyright (C) 2001-2003 MontaVista Software Inc. * Author: Yoichi Yuasa - * Copyright (C) 2004 Yoichi Yuasa - * Copyright (C) 2004 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2004-2005 Yoichi Yuasa + * Copyright (C) 2004 by Ralf Baechle (ralf@linux-mips.org) * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -31,12 +31,18 @@ #include #include +#include #include #include "pci-vr41xx.h" extern struct pci_ops vr41xx_pci_ops; +static void __iomem *pciu_base; + +#define pciu_read(offset) readl(pciu_base + (offset)) +#define pciu_write(offset, value) writel((value), pciu_base + (offset)) + static struct pci_master_address_conversion pci_master_memory1 = { .bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS, .address_mask = PCI_MASTER_MEM1_ADDRESS_MASK, @@ -113,6 +119,13 @@ setup = &vr41xx_pci_controller_unit_setup; + if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL) + return -EBUSY; + + pciu_base = ioremap(PCIU_BASE, PCIU_SIZE); + if (pciu_base == NULL) + return -EBUSY; + /* Disable PCI interrupt */ vr41xx_disable_pciint(); @@ -129,14 +142,14 @@ pci_clock_max = PCI_CLOCK_MAX; vtclock = vr41xx_get_vtclock_frequency(); if (vtclock < pci_clock_max) - writel(EQUAL_VTCLOCK, PCICLKSELREG); + pciu_write(PCICLKSELREG, EQUAL_VTCLOCK); else if ((vtclock / 2) < pci_clock_max) - writel(HALF_VTCLOCK, PCICLKSELREG); + pciu_write(PCICLKSELREG, HALF_VTCLOCK); else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 && (vtclock / 3) < pci_clock_max) - writel(ONE_THIRD_VTCLOCK, PCICLKSELREG); + pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK); else if ((vtclock / 4) < pci_clock_max) - writel(QUARTER_VTCLOCK, PCICLKSELREG); + pciu_write(PCICLKSELREG, QUARTER_VTCLOCK); else { printk(KERN_ERR "PCI Clock is over 33MHz.\n"); return -EINVAL; @@ -151,11 +164,11 @@ MASTER_MSK(master->address_mask) | WINEN | PCIA(master->pci_base_address); - writel(val, PCIMMAW1REG); + pciu_write(PCIMMAW1REG, val); } else { - val = readl(PCIMMAW1REG); + val = pciu_read(PCIMMAW1REG); val &= ~WINEN; - writel(val, PCIMMAW1REG); + pciu_write(PCIMMAW1REG, val); } if (setup->master_memory2 != NULL) { @@ -164,11 +177,11 @@ MASTER_MSK(master->address_mask) | WINEN | PCIA(master->pci_base_address); - writel(val, PCIMMAW2REG); + pciu_write(PCIMMAW2REG, val); } else { - val = readl(PCIMMAW2REG); + val = pciu_read(PCIMMAW2REG); val &= ~WINEN; - writel(val, PCIMMAW2REG); + pciu_write(PCIMMAW2REG, val); } if (setup->target_memory1 != NULL) { @@ -176,11 +189,11 @@ val = TARGET_MSK(target->address_mask) | WINEN | ITA(target->bus_base_address); - writel(val, PCITAW1REG); + pciu_write(PCITAW1REG, val); } else { - val = readl(PCITAW1REG); + val = pciu_read(PCITAW1REG); val &= ~WINEN; - writel(val, PCITAW1REG); + pciu_write(PCITAW1REG, val); } if (setup->target_memory2 != NULL) { @@ -188,11 +201,11 @@ val = TARGET_MSK(target->address_mask) | WINEN | ITA(target->bus_base_address); - writel(val, PCITAW2REG); + pciu_write(PCITAW2REG, val); } else { - val = readl(PCITAW2REG); + val = pciu_read(PCITAW2REG); val &= ~WINEN; - writel(val, PCITAW2REG); + pciu_write(PCITAW2REG, val); } if (setup->master_io != NULL) { @@ -201,50 +214,50 @@ MASTER_MSK(master->address_mask) | WINEN | PCIIA(master->pci_base_address); - writel(val, PCIMIOAWREG); + pciu_write(PCIMIOAWREG, val); } else { - val = readl(PCIMIOAWREG); + val = pciu_read(PCIMIOAWREG); val &= ~WINEN; - writel(val, PCIMIOAWREG); + pciu_write(PCIMIOAWREG, val); } if (setup->exclusive_access == CANNOT_LOCK_FROM_DEVICE) - writel(UNLOCK, PCIEXACCREG); + pciu_write(PCIEXACCREG, UNLOCK); else - writel(0, PCIEXACCREG); + pciu_write(PCIEXACCREG, 0); if (current_cpu_data.cputype == CPU_VR4122) - writel(TRDYV(setup->wait_time_limit_from_irdy_to_trdy), PCITRDYVREG); + pciu_write(PCITRDYVREG, TRDYV(setup->wait_time_limit_from_irdy_to_trdy)); - writel(MLTIM(setup->master_latency_timer), LATTIMEREG); + pciu_write(LATTIMEREG, MLTIM(setup->master_latency_timer)); if (setup->mailbox != NULL) { mailbox = setup->mailbox; val = MBADD(mailbox->base_address) | TYPE_32BITSPACE | MSI_MEMORY | PREF_APPROVAL; - writel(val, MAILBAREG); + pciu_write(MAILBAREG, val); } if (setup->target_window1) { window = setup->target_window1; val = PMBA(window->base_address) | TYPE_32BITSPACE | MSI_MEMORY | PREF_APPROVAL; - writel(val, PCIMBA1REG); + pciu_write(PCIMBA1REG, val); } if (setup->target_window2) { window = setup->target_window2; val = PMBA(window->base_address) | TYPE_32BITSPACE | MSI_MEMORY | PREF_APPROVAL; - writel(val, PCIMBA2REG); + pciu_write(PCIMBA2REG, val); } - val = readl(RETVALREG); + val = pciu_read(RETVALREG); val &= ~RTYVAL_MASK; val |= RTYVAL(setup->retry_limit); - writel(val, RETVALREG); + pciu_write(RETVALREG, val); - val = readl(PCIAPCNTREG); + val = pciu_read(PCIAPCNTREG); val &= ~(TKYGNT | PAPC); switch (setup->arbiter_priority_control) { @@ -262,15 +275,16 @@ if (setup->take_away_gnt_mode == PCI_TAKE_AWAY_GNT_ENABLE) val |= TKYGNT_ENABLE; - writel(val, PCIAPCNTREG); + pciu_write(PCIAPCNTREG, val); - writel(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | - PCI_COMMAND_PARITY | PCI_COMMAND_SERR, COMMANDREG); + pciu_write(COMMANDREG, PCI_COMMAND_IO | PCI_COMMAND_MEMORY | + PCI_COMMAND_MASTER | PCI_COMMAND_PARITY | + PCI_COMMAND_SERR); /* Clear bus error */ - readl(BUSERRADREG); + pciu_read(BUSERRADREG); - writel(BLOODY_CONFIG_DONE, PCIENREG); + pciu_write(PCIENREG, PCIU_CONFIG_DONE); if (setup->mem_resource != NULL) vr41xx_pci_controller.mem_resource = setup->mem_resource; @@ -288,4 +302,4 @@ return 0; } -early_initcall(vr41xx_pciu_init); +arch_initcall(vr41xx_pciu_init); diff -urN -X dontdiff a-orig/arch/mips/pci/pci-vr41xx.h a/arch/mips/pci/pci-vr41xx.h --- a-orig/arch/mips/pci/pci-vr41xx.h Sun Jan 16 22:34:31 2005 +++ a/arch/mips/pci/pci-vr41xx.h Mon Feb 21 01:06:15 2005 @@ -3,7 +3,7 @@ * * Copyright (C) 2002 MontaVista Software Inc. * Author: Yoichi Yuasa - * Copyright (C) 2004 Yoichi Yuasa + * Copyright (C) 2004-2005 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -22,11 +22,14 @@ #ifndef __PCI_VR41XX_H #define __PCI_VR41XX_H -#define PCIMMAW1REG KSEG1ADDR(0x0f000c00) -#define PCIMMAW2REG KSEG1ADDR(0x0f000c04) -#define PCITAW1REG KSEG1ADDR(0x0f000c08) -#define PCITAW2REG KSEG1ADDR(0x0f000c0c) -#define PCIMIOAWREG KSEG1ADDR(0x0f000c10) +#define PCIU_BASE 0x0f000c00UL +#define PCIU_SIZE 0x200UL + +#define PCIMMAW1REG 0x00 +#define PCIMMAW2REG 0x04 +#define PCITAW1REG 0x08 +#define PCITAW2REG 0x0c +#define PCIMIOAWREG 0x10 #define IBA(addr) ((addr) & 0xff000000U) #define MASTER_MSK(mask) (((mask) >> 11) & 0x000fe000U) #define PCIA(addr) (((addr) >> 24) & 0x000000ffU) @@ -34,13 +37,13 @@ #define ITA(addr) (((addr) >> 24) & 0x000000ffU) #define PCIIA(addr) (((addr) >> 24) & 0x000000ffU) #define WINEN 0x1000U -#define PCICONFDREG KSEG1ADDR(0x0f000c14) -#define PCICONFAREG KSEG1ADDR(0x0f000c18) -#define PCIMAILREG KSEG1ADDR(0x0f000c1c) -#define BUSERRADREG KSEG1ADDR(0x0f000c24) +#define PCICONFDREG 0x14 +#define PCICONFAREG 0x18 +#define PCIMAILREG 0x1c +#define BUSERRADREG 0x24 #define EA(reg) ((reg) &0xfffffffc) -#define INTCNTSTAREG KSEG1ADDR(0x0f000c28) +#define INTCNTSTAREG 0x28 #define MABTCLR 0x80000000U #define TRDYCLR 0x40000000U #define PARCLR 0x20000000U @@ -67,34 +70,34 @@ #define MABORT 0x00000002U #define TABORT 0x00000001U -#define PCIEXACCREG KSEG1ADDR(0x0f000c2c) +#define PCIEXACCREG 0x2c #define UNLOCK 0x2U #define EAREQ 0x1U -#define PCIRECONTREG KSEG1ADDR(0x0f000c30) +#define PCIRECONTREG 0x30 #define RTRYCNT(reg) ((reg) & 0x000000ffU) -#define PCIENREG KSEG1ADDR(0x0f000c34) - #define BLOODY_CONFIG_DONE 0x4U -#define PCICLKSELREG KSEG1ADDR(0x0f000c38) +#define PCIENREG 0x34 + #define PCIU_CONFIG_DONE 0x4U +#define PCICLKSELREG 0x38 #define EQUAL_VTCLOCK 0x2U #define HALF_VTCLOCK 0x0U #define ONE_THIRD_VTCLOCK 0x3U #define QUARTER_VTCLOCK 0x1U -#define PCITRDYVREG KSEG1ADDR(0x0f000c3c) +#define PCITRDYVREG 0x3c #define TRDYV(val) ((uint32_t)(val) & 0xffU) -#define PCICLKRUNREG KSEG1ADDR(0x0f000c60) +#define PCICLKRUNREG 0x60 -#define VENDORIDREG KSEG1ADDR(0x0f000d00) -#define DEVICEIDREG KSEG1ADDR(0x0f000d00) -#define COMMANDREG KSEG1ADDR(0x0f000d04) -#define STATUSREG KSEG1ADDR(0x0f000d04) -#define REVIDREG KSEG1ADDR(0x0f000d08) -#define CLASSREG KSEG1ADDR(0x0f000d08) -#define CACHELSREG KSEG1ADDR(0x0f000d0c) -#define LATTIMEREG KSEG1ADDR(0x0f000d0c) +#define VENDORIDREG 0x100 +#define DEVICEIDREG 0x100 +#define COMMANDREG 0x104 +#define STATUSREG 0x104 +#define REVIDREG 0x108 +#define CLASSREG 0x108 +#define CACHELSREG 0x10c +#define LATTIMEREG 0x10c #define MLTIM(val) (((uint32_t)(val) << 7) & 0xff00U) -#define MAILBAREG KSEG1ADDR(0x0f000d10) -#define PCIMBA1REG KSEG1ADDR(0x0f000d14) -#define PCIMBA2REG KSEG1ADDR(0x0f000d18) +#define MAILBAREG 0x110 +#define PCIMBA1REG 0x114 +#define PCIMBA2REG 0x118 #define MBADD(base) ((base) & 0xfffff800U) #define PMBA(base) ((base) & 0xffe00000U) #define PREF 0x8U @@ -104,10 +107,10 @@ #define TYPE_32BITSPACE 0x0U #define MSI 0x1U #define MSI_MEMORY 0x0U -#define INTLINEREG KSEG1ADDR(0x0f000d3c) -#define INTPINREG KSEG1ADDR(0x0f000d3c) -#define RETVALREG KSEG1ADDR(0x0f000d40) -#define PCIAPCNTREG KSEG1ADDR(0x0f000d40) +#define INTLINEREG 0x13c +#define INTPINREG 0x13c +#define RETVALREG 0x140 +#define PCIAPCNTREG 0x140 #define TKYGNT 0x04000000U #define TKYGNT_ENABLE 0x04000000U #define TKYGNT_DISABLE 0x00000000U diff -urN -X dontdiff a-orig/include/asm-mips/vr41xx/pci.h a/include/asm-mips/vr41xx/pci.h --- a-orig/include/asm-mips/vr41xx/pci.h Thu Jan 1 09:00:00 1970 +++ a/include/asm-mips/vr41xx/pci.h Mon Feb 21 01:06:15 2005 @@ -0,0 +1,90 @@ +/* + * Include file for NEC VR4100 series PCI Control Unit. + * + * Copyright (C) 2004-2005 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef __NEC_VR41XX_PCI_H +#define __NEC_VR41XX_PCI_H + +#define PCI_MASTER_ADDRESS_MASK 0x7fffffffU + +struct pci_master_address_conversion { + uint32_t bus_base_address; + uint32_t address_mask; + uint32_t pci_base_address; +}; + +struct pci_target_address_conversion { + uint32_t address_mask; + uint32_t bus_base_address; +}; + +typedef enum { + CANNOT_LOCK_FROM_DEVICE, + CAN_LOCK_FROM_DEVICE, +} pci_exclusive_access_t; + +struct pci_mailbox_address { + uint32_t base_address; +}; + +struct pci_target_address_window { + uint32_t base_address; +}; + +typedef enum { + PCI_ARBITRATION_MODE_FAIR, + PCI_ARBITRATION_MODE_ALTERNATE_0, + PCI_ARBITRATION_MODE_ALTERNATE_B, +} pci_arbiter_priority_control_t; + +typedef enum { + PCI_TAKE_AWAY_GNT_DISABLE, + PCI_TAKE_AWAY_GNT_ENABLE, +} pci_take_away_gnt_mode_t; + +struct pci_controller_unit_setup { + struct pci_master_address_conversion *master_memory1; + struct pci_master_address_conversion *master_memory2; + + struct pci_target_address_conversion *target_memory1; + struct pci_target_address_conversion *target_memory2; + + struct pci_master_address_conversion *master_io; + + pci_exclusive_access_t exclusive_access; + + uint32_t pci_clock_max; + uint8_t wait_time_limit_from_irdy_to_trdy; /* Only VR4122 is supported */ + + struct pci_mailbox_address *mailbox; + struct pci_target_address_window *target_window1; + struct pci_target_address_window *target_window2; + + uint8_t master_latency_timer; + uint8_t retry_limit; + + pci_arbiter_priority_control_t arbiter_priority_control; + pci_take_away_gnt_mode_t take_away_gnt_mode; + + struct resource *mem_resource; + struct resource *io_resource; +}; + +extern void vr41xx_pciu_setup(struct pci_controller_unit_setup *setup); + +#endif /* __NEC_VR41XX_PCI_H */ diff -urN -X dontdiff a-orig/include/asm-mips/vr41xx/vr41xx.h a/include/asm-mips/vr41xx/vr41xx.h --- a-orig/include/asm-mips/vr41xx/vr41xx.h Thu May 27 08:14:44 2004 +++ a/include/asm-mips/vr41xx/vr41xx.h Mon Feb 21 01:06:15 2005 @@ -274,74 +274,4 @@ */ extern void vr41xx_dsiu_init(void); -/* - * PCI Control Unit - */ -#define PCI_MASTER_ADDRESS_MASK 0x7fffffffU - -struct pci_master_address_conversion { - uint32_t bus_base_address; - uint32_t address_mask; - uint32_t pci_base_address; -}; - -struct pci_target_address_conversion { - uint32_t address_mask; - uint32_t bus_base_address; -}; - -typedef enum { - CANNOT_LOCK_FROM_DEVICE, - CAN_LOCK_FROM_DEVICE, -} pci_exclusive_access_t; - -struct pci_mailbox_address { - uint32_t base_address; -}; - -struct pci_target_address_window { - uint32_t base_address; -}; - -typedef enum { - PCI_ARBITRATION_MODE_FAIR, - PCI_ARBITRATION_MODE_ALTERNATE_0, - PCI_ARBITRATION_MODE_ALTERNATE_B, -} pci_arbiter_priority_control_t; - -typedef enum { - PCI_TAKE_AWAY_GNT_DISABLE, - PCI_TAKE_AWAY_GNT_ENABLE, -} pci_take_away_gnt_mode_t; - -struct pci_controller_unit_setup { - struct pci_master_address_conversion *master_memory1; - struct pci_master_address_conversion *master_memory2; - - struct pci_target_address_conversion *target_memory1; - struct pci_target_address_conversion *target_memory2; - - struct pci_master_address_conversion *master_io; - - pci_exclusive_access_t exclusive_access; - - uint32_t pci_clock_max; - uint8_t wait_time_limit_from_irdy_to_trdy; /* Only VR4122 is supported */ - - struct pci_mailbox_address *mailbox; - struct pci_target_address_window *target_window1; - struct pci_target_address_window *target_window2; - - uint8_t master_latency_timer; - uint8_t retry_limit; - - pci_arbiter_priority_control_t arbiter_priority_control; - pci_take_away_gnt_mode_t take_away_gnt_mode; - - struct resource *mem_resource; - struct resource *io_resource; -}; - -extern void vr41xx_pciu_setup(struct pci_controller_unit_setup *setup); - #endif /* __NEC_VR41XX_H */ From yuasa@hh.iij4u.or.jp Mon Mar 7 16:44:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 16:44:42 +0000 (GMT) Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:46055 "EHLO mo01.iij4u.or.jp") by linux-mips.org with ESMTP id ; Mon, 7 Mar 2005 16:44:26 +0000 Received: MO(mo01)id j27GiNDI000647; Tue, 8 Mar 2005 01:44:23 +0900 (JST) Received: MDO(mdo00) id j27GiMf2027770; Tue, 8 Mar 2005 01:44:23 +0900 (JST) Received: 4UMRO00 id j27GiL0h007645; Tue, 8 Mar 2005 01:44:22 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Tue, 8 Mar 2005 01:44:20 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux Message-Id: <20050308014420.6253f8ce.yuasa@hh.iij4u.or.jp> In-Reply-To: <20050119152151.7b756560.yuasa@hh.iij4u.or.jp> References: <20050115013112Z8225557-1340+1316@linux-mips.org> <20050119134211.2c0e24f5.yuasa@hh.iij4u.or.jp> <20050119143146.09982d63.yuasa@hh.iij4u.or.jp> <20050119152151.7b756560.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Content-Length: 4155 Lines: 140 Hello Ralf and Maciej, On Wed, 19 Jan 2005 15:21:51 +0900 Yoichi Yuasa wrote: > Hi Maciej, > > On Wed, 19 Jan 2005 05:35:29 +0000 (GMT) > "Maciej W. Rozycki" wrote: > > > On Wed, 19 Jan 2005, Yoichi Yuasa wrote: > > > > > > Neither of these uses any CONFIG_* macros. > > > > > > I'm making patch for giu.c and icu.c. > > > These patches need it. > > > > Then please just include what you need within these patches. That's the > > usual way of doing stuff. > > Ok, I'll send a patch including get back and add new line. Sorry for the delay. Next I'll send giu.c update. Yoichi Signed-off-by: Yoichi Yuasa diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig --- a-orig/arch/mips/vr41xx/Kconfig Mon Jan 31 05:45:36 2005 +++ a/arch/mips/vr41xx/Kconfig Tue Mar 8 01:34:14 2005 @@ -97,6 +97,10 @@ bool "Add PCI control unit support of NEC VR4100 series" depends on MACH_VR41XX && PCI +config GPIO_VR41XX + bool "Add General-purpose I/O unit support of NEC VR4100 series" + depends on MACH_VR41XX + config VRC4171 tristate "Add NEC VRC4171 companion chip support" depends on MACH_VR41XX && ISA diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/Makefile a/arch/mips/vr41xx/common/Makefile --- a-orig/arch/mips/vr41xx/common/Makefile Thu Feb 26 00:23:50 2004 +++ a/arch/mips/vr41xx/common/Makefile Fri Mar 4 17:29:00 2005 @@ -2,7 +2,8 @@ # Makefile for common code of the NEC VR4100 series. # -obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o +obj-y += bcu.o cmu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o +obj-$(CONFIG_GPIO_VR41XX) += giu.o obj-$(CONFIG_SERIAL_8250) += serial.o obj-$(CONFIG_VRC4171) += vrc4171.o obj-$(CONFIG_VRC4173) += vrc4173.o diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/icu.c a/arch/mips/vr41xx/common/icu.c --- a-orig/arch/mips/vr41xx/common/icu.c Sun Jan 16 22:34:31 2005 +++ a/arch/mips/vr41xx/common/icu.c Tue Mar 8 01:08:13 2005 @@ -3,8 +3,7 @@ * * Copyright (C) 2001-2002 MontaVista Software Inc. * Author: Yoichi Yuasa - * Copyright (C) 2003-2004 Yoichi Yuasa - * Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2003-2005 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -29,6 +28,7 @@ * Yoichi Yuasa * - Coped with INTASSIGN of NEC VR4133. */ +#include #include #include #include @@ -45,8 +45,10 @@ extern asmlinkage void vr41xx_handle_interrupt(void); +#ifdef CONFIG_GPIO_VR41XX extern void init_vr41xx_giuint_irq(void); extern void giuint_irq_dispatch(struct pt_regs *regs); +#endif static uint32_t icu1_base; static uint32_t icu2_base; @@ -672,9 +674,11 @@ for (i = 0; i < 16; i++) { if (intnum == sysint1_assign[i] && (mask1 & ((uint16_t)1 << i))) { +#ifdef CONFIG_GPIO_VR41XX if (i == 8) giuint_irq_dispatch(regs); else +#endif do_IRQ(SYSINT1_IRQ(i), regs); return; } @@ -698,8 +702,10 @@ /*=======================================================================*/ -static int __init vr41xx_icu_init(void) +static inline void init_vr41xx_icu_irq(void) { + int i; + switch (current_cpu_data.cputype) { case CPU_VR4111: case CPU_VR4121: @@ -723,17 +729,6 @@ write_icu2(0, MSYSINT2REG); write_icu2(0xffff, MGIUINTHREG); - return 0; -} - -early_initcall(vr41xx_icu_init); - -/*=======================================================================*/ - -static inline void init_vr41xx_icu_irq(void) -{ - int i; - for (i = SYSINT1_IRQ_BASE; i <= SYSINT1_IRQ_LAST; i++) irq_desc[i].handler = &sysint1_irq_type; @@ -751,7 +746,9 @@ { mips_cpu_irq_init(MIPS_CPU_IRQ_BASE); init_vr41xx_icu_irq(); +#ifdef CONFIG_GPIO_VR41XX init_vr41xx_giuint_irq(); +#endif set_except_vector(0, vr41xx_handle_interrupt); } From maillist@jg555.com Mon Mar 7 17:21:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 17:21:50 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:55013 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Mon, 7 Mar 2005 17:21:19 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 07 Mar 2005 09:21:17 -0800 id 00008471.422C8D8D.00005233 Message-ID: <422C8D6A.6060904@jg555.com> Date: Mon, 07 Mar 2005 09:20:42 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: IPTables 1.3.x fails on RaQ2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 882 Lines: 24 I've been trying to figure out why the current iptables fails on the 2.6.9 and 2.6.11 MIPS builds. It seems that a file cpu-features-overrides.h is missing for the Cobalt builds. Are their plans for one, or is there a patch out there so we can get it added. Here is the error message on the IPTables build, I still don't understand why they are checking for that myself. # ./iptables install Verifying iptables-1.3.1.tar.bz2 Downloading iptables-1.3.1.tar.bz2 Creating Local SHA1 file for iptables-1.3.1.tar.bz2 Installing iptables-1.3.1 Unpacking iptables-1.3.1.tar.bz2 Making dependencies: please wait... Something wrong... deleting dependencies. make: *** [cpu-feature-overrides.h] Error 1 -----Error at Build has occured----- Exiting -- ---- Jim Gifford maillist@jg555.com From freshy98@gmx.net Mon Mar 7 17:35:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 17:35:31 +0000 (GMT) Received: from mail.gmx.net ([IPv6:::ffff:213.165.64.20]:4235 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Mon, 7 Mar 2005 17:35:16 +0000 Received: (qmail invoked by alias); 07 Mar 2005 17:35:09 -0000 Received: from kf-pij-tg01-0933.dial.kabelfoon.nl (EHLO [192.168.1.61]) (62.45.179.166) by mail.gmx.net (mp027) with SMTP; 07 Mar 2005 18:35:09 +0100 X-Authenticated: #11016536 Message-ID: <422C9142.8090007@gmx.net> Date: Mon, 07 Mar 2005 18:37:06 +0100 From: freshy98 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> In-Reply-To: <422C8D6A.6060904@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freshy98@gmx.net Precedence: bulk X-list: linux-mips Content-Length: 1297 Lines: 38 Jim, I am running iptables-1.2.11-r3 on my Gentoo installed Cobalt Qube2 and it compiles alright. If I remember correctly I have tried a higher version which failed on cpu-feature-overrides.h too. My kernel is linux-2.6.10-20050115 which is in the Portage tree of Gentoo and is based upon CVS. So far this machines runs for 14 days without a problem. It runs iptables with shorewall. Regards, Tom Jim Gifford wrote: > I've been trying to figure out why the current iptables fails on the > 2.6.9 and 2.6.11 MIPS builds. It seems that a file > cpu-features-overrides.h is missing for the Cobalt builds. Are their > plans for one, or is there a patch out there so we can get it added. > Here is the error message on the IPTables build, I still don't > understand why they are checking for that myself. > > # ./iptables install > Verifying iptables-1.3.1.tar.bz2 > Downloading iptables-1.3.1.tar.bz2 > Creating Local SHA1 file for iptables-1.3.1.tar.bz2 > Installing iptables-1.3.1 > Unpacking iptables-1.3.1.tar.bz2 > Making dependencies: please wait... > Something wrong... deleting dependencies. > make: *** [cpu-feature-overrides.h] Error 1 > -----Error at Build has occured----- > Exiting > From rsivaprasad@gmail.com Mon Mar 7 23:59:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Mar 2005 23:59:41 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.199]:47506 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Mon, 7 Mar 2005 23:59:24 +0000 Received: by rproxy.gmail.com with SMTP id y7so1297847rne for ; Mon, 07 Mar 2005 15:59:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iclVCWtmoix40bCcSMeZ4LGEKKwOwTgs0ymduKTEQHOeyYPWzH3KcWeOUxehTyNffJv8EKuKA0mUziOlA5SFid4wCikDuVqdK2Yc9Pm9TbKptBjlh10BbLvX8sufJKoHjCseSRD7FnaIgSo3z1z9fOtRILM7bdEgiitIgxZ7hQM= Received: by 10.39.2.65 with SMTP id e65mr37369rni; Mon, 07 Mar 2005 15:58:33 -0800 (PST) Received: by 10.38.104.32 with HTTP; Mon, 7 Mar 2005 15:58:33 -0800 (PST) Message-ID: <6a95eefb050307155815cf14fb@mail.gmail.com> Date: Mon, 7 Mar 2005 15:58:33 -0800 From: Siva Prasad Reply-To: Siva Prasad To: linux-mips Subject: Re: [PATCH 2.6] update PCI code for VR41xx In-Reply-To: <20050308012815.0a02095e.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050308012815.0a02095e.yuasa@hh.iij4u.or.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsivaprasad@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 225 Lines: 15 Hello, I am looking for Linux distribution that works on Atheros AR5312 (MIPS 4kc processor core). Any pointer towards this direction is appreciated. * Boot loader * Linux distribution * Ethernet driver etc. Thanks siva From rsivaprasad@gmail.com Tue Mar 8 00:00:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 00:00:25 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.202]:29080 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 00:00:07 +0000 Received: by rproxy.gmail.com with SMTP id y7so1298024rne for ; Mon, 07 Mar 2005 16:00:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=QvaJKQEGtb/71Rx+Xsn9911sm8vCQTgj+W79tBvgttwQj6iAwqom1uIQrKqpduQ6SDWdqKGTAhOGE0ok1Zt23ZRbvZ2gBBwj3JOmSSD0pSsqfYzuNqA6RYvo4YijYkn5wr5DUNbcGHn405uPtrc7ciqEu8EyLSEP0cszX/5nlnM= Received: by 10.38.164.40 with SMTP id m40mr100036rne; Mon, 07 Mar 2005 16:00:02 -0800 (PST) Received: by 10.38.104.32 with HTTP; Mon, 7 Mar 2005 16:00:02 -0800 (PST) Message-ID: <6a95eefb05030716005d634fd1@mail.gmail.com> Date: Mon, 7 Mar 2005 16:00:02 -0800 From: Siva Prasad Reply-To: Siva Prasad To: linux-mips Subject: Linux distribution on Atheros AR5312 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsivaprasad@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 225 Lines: 15 Hello, I am looking for Linux distribution that works on Atheros AR5312 (MIPS 4kc processor core). Any pointer towards this direction is appreciated. * Boot loader * Linux distribution * Ethernet driver etc. Thanks siva From kumba@gentoo.org Tue Mar 8 02:27:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 02:27:18 +0000 (GMT) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:1486 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 02:27:02 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (rwcrmhc13) with ESMTP id <200503080226550150040cc6e>; Tue, 8 Mar 2005 02:26:55 +0000 Message-ID: <422D0D64.2080402@gentoo.org> Date: Mon, 07 Mar 2005 21:26:44 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freshy98 CC: Jim Gifford , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> In-Reply-To: <422C9142.8090007@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 2093 Lines: 57 freshy98 wrote: > Jim, > > I am running iptables-1.2.11-r3 on my Gentoo installed Cobalt Qube2 and > it compiles alright. > If I remember correctly I have tried a higher version which failed on > cpu-feature-overrides.h too. > > My kernel is linux-2.6.10-20050115 which is in the Portage tree of > Gentoo and is based upon CVS. > So far this machines runs for 14 days without a problem. > It runs iptables with shorewall. > > Regards, > > Tom > > > Jim Gifford wrote: > >> I've been trying to figure out why the current iptables fails on the >> 2.6.9 and 2.6.11 MIPS builds. It seems that a file >> cpu-features-overrides.h is missing for the Cobalt builds. Are their >> plans for one, or is there a patch out there so we can get it added. >> Here is the error message on the IPTables build, I still don't >> understand why they are checking for that myself. >> >> # ./iptables install >> Verifying iptables-1.3.1.tar.bz2 >> Downloading iptables-1.3.1.tar.bz2 >> Creating Local SHA1 file for iptables-1.3.1.tar.bz2 >> Installing iptables-1.3.1 >> Unpacking iptables-1.3.1.tar.bz2 >> Making dependencies: please wait... >> Something wrong... deleting dependencies. >> make: *** [cpu-feature-overrides.h] Error 1 >> -----Error at Build has occured----- >> Exiting This is a headers problem, mainly in 2.6. 2.6 isn't safe out-of-the-box for userland consumption. I've been toying with some 2.6.10 headers from LMO cvs on the gentoo side of things, where we have an "appCompat" patch that plugs up a alot of the leaky holes in 2.6.x headers, but I still have to analyze the patch and add in some mips-specific bits before these headers can be considered remotely sane for even testing. Those running other distros will probably need similar modifications to their headers to make them userland-friendly. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From maillist@jg555.com Tue Mar 8 04:20:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 04:21:17 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:16530 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 04:20:54 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 07 Mar 2005 20:20:52 -0800 id 0000847A.422D2824.00006ABD Message-ID: <422D2801.2060903@jg555.com> Date: Mon, 07 Mar 2005 20:20:17 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumba CC: Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> In-Reply-To: <422D0D64.2080402@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 182 Lines: 4 I just don't understand why iptables needs that file at all, I can't find anything in it that uses it. I'm going to search again, and I will post my results once I figure it out. From kumba@gentoo.org Tue Mar 8 05:40:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 05:40:58 +0000 (GMT) Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:2537 "EHLO rwcrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 05:40:41 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (rwcrmhc11) with ESMTP id <2005030805403401300ocl4ke>; Tue, 8 Mar 2005 05:40:35 +0000 Message-ID: <422D3AC9.4020601@gentoo.org> Date: Tue, 08 Mar 2005 00:40:25 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> In-Reply-To: <422D2801.2060903@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1576 Lines: 30 Jim Gifford wrote: > I just don't understand why iptables needs that file at all, I can't > find anything in it that uses it. I'm going to search again, and I will > post my results once I figure it out. iptables doesn't need it. It's one of those funky #include chains. include A includes B which includes C which includes Q and so on until it tries including a file it can't find. This is because there are a series of mach-* machine subdirs in include/asm-mips that each contain headers specific to a particular machine type (like spaces.h, among other things). I haven't delved into the specifics (someone else here can explain it more), but when the kernel builds, based upon the configuration of the kernel, it knows which include/asm-mips/mach-* directory to look in to snag the headers it needs. Userland doesn't know this, so for headers used in userland, you need to patch things abit. Otherwise, they break. http://tinyurl.com/5grah <-- appCompat patch used in Gentoo's linux-headers 2.6.10 ebuild. It lacks mips-specific bits, but you can look at how x86 handles some of its include/asm-i386/mach-* sections for how we're working around these issues. It's all a hack really, until someone either fixes userland to never use kernel headers, or the kernel-side finds a way to create userland-friendly headers (but I don't see any of this happening anytime soon). --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From freshy98@gmx.net Tue Mar 8 06:46:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 06:46:57 +0000 (GMT) Received: from mail.gmx.net ([IPv6:::ffff:213.165.64.20]:44234 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Tue, 8 Mar 2005 06:46:40 +0000 Received: (qmail invoked by alias); 08 Mar 2005 06:46:34 -0000 Received: from kf-pij-tg01-0933.dial.kabelfoon.nl (EHLO [192.168.1.61]) (62.45.179.166) by mail.gmx.net (mp018) with SMTP; 08 Mar 2005 07:46:34 +0100 X-Authenticated: #11016536 Message-ID: <422D4A49.9020504@gmx.net> Date: Tue, 08 Mar 2005 07:46:33 +0100 From: freshy98 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumba CC: Jim Gifford , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> In-Reply-To: <422D3AC9.4020601@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freshy98@gmx.net Precedence: bulk X-list: linux-mips Content-Length: 1841 Lines: 42 I do not use linux-headers-2.6.x on my Qube2, but iptables still b0rked on anything higher then 1.2.11-r3. If I am correct then mips-headers is the equivelant of linux-headers? In that case I have 2.4.21-r3. My Qube2 acts as my firewall and so I have tried several versions the first time I installed it. At that time iptables wasn't marked stable on mips. Kumba wrote: > Jim Gifford wrote: > >> I just don't understand why iptables needs that file at all, I can't >> find anything in it that uses it. I'm going to search again, and I >> will post my results once I figure it out. > > > iptables doesn't need it. It's one of those funky #include chains. > include A includes B which includes C which includes Q and so on until > it tries including a file it can't find. This is because there are a > series of mach-* machine subdirs in include/asm-mips that each contain > headers specific to a particular machine type (like spaces.h, among > other things). I haven't delved into the specifics (someone else here > can explain it more), but when the kernel builds, based upon the > configuration of the kernel, it knows which include/asm-mips/mach-* > directory to look in to snag the headers it needs. Userland doesn't > know this, so for headers used in userland, you need to patch things > abit. Otherwise, they break. > > http://tinyurl.com/5grah <-- appCompat patch used in Gentoo's > linux-headers 2.6.10 ebuild. It lacks mips-specific bits, but you can > look at how x86 handles some of its include/asm-i386/mach-* sections > for how we're working around these issues. It's all a hack really, > until someone either fixes userland to never use kernel headers, or > the kernel-side finds a way to create userland-friendly headers (but I > don't see any of this happening anytime soon). > > > --Kumba > From maillist@jg555.com Tue Mar 8 07:35:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 07:36:12 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:23704 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 07:35:56 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 07 Mar 2005 23:35:53 -0800 id 0000803E.422D55D9.00001840 Message-ID: <422D55B6.4010300@jg555.com> Date: Mon, 07 Mar 2005 23:35:18 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freshy98 CC: Kumba , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> <422D4A49.9020504@gmx.net> In-Reply-To: <422D4A49.9020504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 795 Lines: 27 I found the culprit, but don't know what the proper fix is. File - What to remove or comment out /usr/src/linux/include/asm/cpu-features.h - #include /usr/src/linux/include/asm/addrspace.h - #include But it still fails, because it looks at the headers in /usr/include and the ones is /usr/src/linux/include, which is what the problem is. Namely socket.h What I noticed is some of the mips architectures includes have these files and some do not. A workaround for those who use the linux-libc-headers to build iptables with the following commands, but I would still comment out those files to prevent other build issues later make KERNEL_DIR=/usr But I'm not sure of the stability and the functionality. -- ---- Jim Gifford maillist@jg555.com From jpfoster@exterity.co.uk Tue Mar 8 13:12:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 13:13:22 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:36266 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 13:12:59 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 13:14:22 +0000 Subject: clear_user_page in page.h From: JP Foster To: linux-mips Content-Type: text/plain Date: Tue, 08 Mar 2005 13:12:52 +0000 Message-Id: <1110287573.30647.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.6 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2005 13:14:22.0437 (UTC) FILETIME=[BE6CB950:01C523E0] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jp.foster@exterity.co.uk Precedence: bulk X-list: linux-mips Content-Length: 581 Lines: 20 Hi all, I'm building the video4linux drivers as modules and the video-buf driver can't load as it has no reference to shm_align_mask and flush_data_cache_page. These are needed by asm-mips/page.h for the inline funcs, pages_do_alias and clear/copy_user_page. How should shm_align_mask and flush_data_cache_page. be exported to modules? Most other asm-xxx/page.h doesn't need any externs, all is #defined within page.h or files included by it. Any ideas how I deal with this? Presumably other modules will be affected by this. -- jp.foster@exterity.co.uk Digital Simplicity From ralf@linux-mips.org Tue Mar 8 13:25:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 13:26:08 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:34574 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 13:25:53 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j28DO9qY012898; Tue, 8 Mar 2005 13:24:09 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j28DO8ZM012897; Tue, 8 Mar 2005 13:24:08 GMT Date: Tue, 8 Mar 2005 13:24:08 +0000 From: Ralf Baechle To: Jim Gifford Cc: freshy98 , Kumba , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 Message-ID: <20050308132408.GB9811@linux-mips.org> References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> <422D4A49.9020504@gmx.net> <422D55B6.4010300@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422D55B6.4010300@jg555.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1052 Lines: 25 On Mon, Mar 07, 2005 at 11:35:18PM -0800, Jim Gifford wrote: > File - What to remove or comment out > /usr/src/linux/include/asm/cpu-features.h - #include > > /usr/src/linux/include/asm/addrspace.h - #include > > But it still fails, because it looks at the headers in /usr/include and > the ones is /usr/src/linux/include, which is what the problem is. Namely > socket.h > > What I noticed is some of the mips architectures includes have these > files and some do not. These headers are search along a search path until found. Typically that path consists of two directories such as mach-ip22 followed by mach-generic as last. This allows eleminating duplicated header files. A bad side effect - users frequently forget adding files such as cpu-features-override.h which contain a detailed description of the CPU properties on a particular platform. Without a platform specific file the kernel will basically fallback to generic code that is slow but supports almost every CPU in the universe. Ralf From kumba@gentoo.org Tue Mar 8 13:46:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 13:47:09 +0000 (GMT) Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:56986 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 13:46:54 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (sccrmhc11) with ESMTP id <20050308134648011005nv4re>; Tue, 8 Mar 2005 13:46:48 +0000 Message-ID: <422DACBF.4040108@gentoo.org> Date: Tue, 08 Mar 2005 08:46:39 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> <422D4A49.9020504@gmx.net> <422D55B6.4010300@jg555.com> In-Reply-To: <422D55B6.4010300@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1468 Lines: 43 Jim Gifford wrote: > I found the culprit, but don't know what the proper fix is. > > File - What to remove or comment out > /usr/src/linux/include/asm/cpu-features.h - #include > > /usr/src/linux/include/asm/addrspace.h - #include > > But it still fails, because it looks at the headers in /usr/include and > the ones is /usr/src/linux/include, which is what the problem is. Namely > socket.h > > What I noticed is some of the mips architectures includes have these > files and some do not. > > A workaround for those who use the linux-libc-headers to build iptables > with the following commands, but I would still comment out those files > to prevent other build issues later > > make KERNEL_DIR=/usr > > But I'm not sure of the stability and the functionality. You need to patch the headers for these things -- i.e.: #include becomes #include Same goes for references to spaces.h, and most other files directly referenced as '#include ' in 'include/asm-mips/*'. mach-generic is best suited for this despite the actual machine because these are geared for userland, and userland shouldn't really care about what particular mips machine it's running on. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From ralf@linux-mips.org Tue Mar 8 14:09:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 14:09:19 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:9489 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 14:09:05 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j28E7lFx015431; Tue, 8 Mar 2005 14:07:47 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j28E7lRg015409; Tue, 8 Mar 2005 14:07:47 GMT Date: Tue, 8 Mar 2005 14:07:47 +0000 From: Ralf Baechle To: JP Foster Cc: linux-mips Subject: Re: clear_user_page in page.h Message-ID: <20050308140747.GC9811@linux-mips.org> References: <1110287573.30647.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110287573.30647.16.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 779 Lines: 23 On Tue, Mar 08, 2005 at 01:12:52PM +0000, JP Foster wrote: > Hi all, > I'm building the video4linux drivers as modules and the video-buf driver > can't load as it has no reference to shm_align_mask and > flush_data_cache_page. > > These are needed by asm-mips/page.h for the inline funcs, pages_do_alias > and clear/copy_user_page. > How should shm_align_mask and flush_data_cache_page. be exported to > modules? > > Most other asm-xxx/page.h doesn't need any externs, all is #defined > within page.h or files included by it. > > Any ideas how I deal with this? Presumably other modules will be > affected by this. The code in question should be considered broken anyway but for the time being until this is actually fixed I'm going to add the two symbol exports. Ralf From jpfoster@exterity.co.uk Tue Mar 8 15:11:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 15:11:40 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:55097 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 15:11:25 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 15:12:49 +0000 Subject: Re: clear_user_page in page.h From: JP Foster To: linux-mips In-Reply-To: <20050308140747.GC9811@linux-mips.org> References: <1110287573.30647.16.camel@localhost.localdomain> <20050308140747.GC9811@linux-mips.org> Content-Type: text/plain Date: Tue, 08 Mar 2005 15:11:20 +0000 Message-Id: <1110294681.30647.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.6 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2005 15:12:50.0015 (UTC) FILETIME=[4ADF0EF0:01C523F1] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jp.foster@exterity.co.uk Precedence: bulk X-list: linux-mips Content-Length: 153 Lines: 7 Great, that's what I did here. When you say the code in question do you mean the v4l stuff or page.h? -- jp.foster@exterity.co.uk Digital Simplicity From maillist@jg555.com Tue Mar 8 16:30:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 16:31:10 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:26791 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 16:30:54 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 08 Mar 2005 08:30:52 -0800 id 000084E8.422DD33C.0000110B Message-ID: <422DD318.9020804@jg555.com> Date: Tue, 08 Mar 2005 08:30:16 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Kumba , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> <422D4A49.9020504@gmx.net> <422D55B6.4010300@jg555.com> <20050308132408.GB9811@linux-mips.org> In-Reply-To: <20050308132408.GB9811@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 526 Lines: 14 Ralf and other Linux-MIPS readers, I checked the linux-libc-headers for those files, and they are not there. I'm tried fighting this battle with netfilter before and they won't budge from the fact that they build iptables from the headers in /usr/src/linux, if you use my make KERNEL_DIR=/usr, the problem doesn't exist it's only when we build from the raw kernel headers. So what method is the proper method, building from the raw headers or santized ones like linux-libc? -- ---- Jim Gifford maillist@jg555.com From ralf@linux-mips.org Tue Mar 8 16:38:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Mar 2005 16:38:45 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:10523 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Mar 2005 16:38:30 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j28Gb1uB009273; Tue, 8 Mar 2005 16:37:01 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j28Gb0oF009272; Tue, 8 Mar 2005 16:37:00 GMT Date: Tue, 8 Mar 2005 16:37:00 +0000 From: Ralf Baechle To: Jim Gifford Cc: Kumba , Linux MIPS List Subject: Re: IPTables 1.3.x fails on RaQ2 Message-ID: <20050308163700.GA2099@linux-mips.org> References: <422C8D6A.6060904@jg555.com> <422C9142.8090007@gmx.net> <422D0D64.2080402@gentoo.org> <422D2801.2060903@jg555.com> <422D3AC9.4020601@gentoo.org> <422D4A49.9020504@gmx.net> <422D55B6.4010300@jg555.com> <20050308132408.GB9811@linux-mips.org> <422DD318.9020804@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422DD318.9020804@jg555.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 706 Lines: 15 On Tue, Mar 08, 2005 at 08:30:16AM -0800, Jim Gifford wrote: > Ralf and other Linux-MIPS readers, > I checked the linux-libc-headers for those files, and they are not > there. I'm tried fighting this battle with netfilter before and they > won't budge from the fact that they build iptables from the headers in > /usr/src/linux, if you use my make KERNEL_DIR=/usr, the problem doesn't > exist it's only when we build from the raw kernel headers. So what > method is the proper method, building from the raw headers or santized > ones like linux-libc? The sucky but official policy Linus has given out is that userland should not include kernel headers. Which means anything else is ok. Ralf From mailinglist.linux@gmail.com Wed Mar 9 04:26:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Mar 2005 04:27:02 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.199]:13061 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Wed, 9 Mar 2005 04:26:47 +0000 Received: by wproxy.gmail.com with SMTP id 37so99116wra for ; Tue, 08 Mar 2005 20:26:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=UEWdjqUAiVW5/MkIaFoBtgH1XLrGXz7PcNFcfmkfeX66ZlS3cN9xXMSI7m6TISrwrX32MEGXAhtO19wno0jNu1uOFlIvJP2PA0/la2MlUacyeY5GGft4rV+ttTghWPALyHGo2ZY7pH+EfnDKpcQOZX7eMUkYi8lYKZ6D/hmff98= Received: by 10.54.45.41 with SMTP id s41mr457518wrs; Tue, 08 Mar 2005 20:26:41 -0800 (PST) Received: by 10.54.56.8 with HTTP; Tue, 8 Mar 2005 20:26:40 -0800 (PST) Message-ID: <77fd3fe0050308202654a4432a@mail.gmail.com> Date: Tue, 8 Mar 2005 20:26:40 -0800 From: Linux Mailinglist Reply-To: Linux Mailinglist To: linux-mips@linux-mips.org Subject: Linux 2.6 support for Brecis MSP2100 processor ! Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mailinglist.linux@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 104 Lines: 6 Hi all ! Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 processor ? Thanks Srinivasan From ralf@linux-mips.org Wed Mar 9 17:30:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Mar 2005 17:31:12 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:57868 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Mar 2005 17:30:57 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j29HUijk024057; Wed, 9 Mar 2005 17:30:44 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j29HUiWC024056; Wed, 9 Mar 2005 17:30:44 GMT Date: Wed, 9 Mar 2005 17:30:44 +0000 From: Ralf Baechle To: Linux Mailinglist Cc: linux-mips@linux-mips.org Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! Message-ID: <20050309173044.GA18688@linux-mips.org> References: <77fd3fe0050308202654a4432a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77fd3fe0050308202654a4432a@mail.gmail.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 239 Lines: 8 On Tue, Mar 08, 2005 at 08:26:40PM -0800, Linux Mailinglist wrote: > Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 processor ? That's not a processor but a whole SOC and the processor is a 4Km which is supported. Ralf From ralf@linux-mips.org Wed Mar 9 17:45:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Mar 2005 17:46:11 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:39690 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Mar 2005 17:45:57 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j29HjcXo024643; Wed, 9 Mar 2005 17:45:38 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j29HjcKm024642; Wed, 9 Mar 2005 17:45:38 GMT Date: Wed, 9 Mar 2005 17:45:38 +0000 From: Ralf Baechle To: JP Foster Cc: linux-mips Subject: Re: clear_user_page in page.h Message-ID: <20050309174537.GB18688@linux-mips.org> References: <1110287573.30647.16.camel@localhost.localdomain> <20050308140747.GC9811@linux-mips.org> <1110294681.30647.44.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110294681.30647.44.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 226 Lines: 8 On Tue, Mar 08, 2005 at 03:11:20PM +0000, JP Foster wrote: > Great, that's what I did here. > When you say the code in question do you mean the v4l stuff or page.h? Linux mm. The (brain-)damage goes beyond page.h. Ralf From deltha@analog.ro Wed Mar 9 18:09:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Mar 2005 18:09:54 +0000 (GMT) Received: from main.analog.ro ([IPv6:::ffff:81.196.32.141]:9117 "EHLO main.analog.ro") by linux-mips.org with ESMTP id ; Wed, 9 Mar 2005 18:09:40 +0000 Received: from www.analog.ro (localhost [127.0.0.1]) by main.analog.ro (8.13.1/8.13.1) with ESMTP id j29IK2bC015087 for ; Wed, 9 Mar 2005 20:20:02 +0200 Received: from 81.196.32.141 (proxying for unknown) (SquirrelMail authenticated user deltha); by www.analog.ro with HTTP; Wed, 9 Mar 2005 20:20:02 +0200 (EET) Message-ID: <40224.81.196.32.141.1110392402.squirrel@www.analog.ro> In-Reply-To: <20050309173044.GA18688@linux-mips.org> References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> Date: Wed, 9 Mar 2005 20:20:02 +0200 (EET) Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! From: deltha@analog.ro To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.3a-6.FC3 X-Mailer: SquirrelMail/1.4.3a-6.FC3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: deltha@analog.ro Precedence: bulk X-list: linux-mips Content-Length: 366 Lines: 19 > On Tue, Mar 08, 2005 at 08:26:40PM -0800, Linux Mailinglist wrote: > >> Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 processor ? > > That's not a processor but a whole SOC and the processor is a 4Km which > is supported. > > Ralf > Hi, Brecis will support it if you buy more than 100 devices. Best regards, Ruijinschi Remus deltha@analog.ro From ralf@linux-mips.org Thu Mar 10 17:29:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Mar 2005 17:29:31 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:1301 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 10 Mar 2005 17:29:13 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2AHSeZV027704; Thu, 10 Mar 2005 17:28:40 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2AHSeae027703; Thu, 10 Mar 2005 17:28:40 GMT Date: Thu, 10 Mar 2005 17:28:40 +0000 From: Ralf Baechle To: Panagiotis Issaris Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] qtronix missing failure handling Message-ID: <20050310172840.GD26269@linux-mips.org> References: <20050305150844.GA7544@mech.kuleuven.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305150844.GA7544@mech.kuleuven.ac.be> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 346 Lines: 15 On Sat, Mar 05, 2005 at 04:08:44PM +0100, Panagiotis Issaris wrote: > Hi, > > The Qtronix keyboard driver doesn't handle the possible failure of memory > allocation. Thanks, applied. Please copy Linux/MIPS-specific patches to me or linux-mips@linux-mips.org; it was more a coincidence that I noticed your patch on this list. Thanks, Ralf From martini@c2micro.com Thu Mar 10 23:42:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Mar 2005 23:43:03 +0000 (GMT) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:20221 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Thu, 10 Mar 2005 23:42:47 +0000 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id 0181E25C95F; Thu, 10 Mar 2005 15:42:45 -0800 (PST) Message-ID: <4230DB4C.7090103@c2micro.com> Date: Thu, 10 Mar 2005 15:42:04 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org, Steve Stone Subject: initrd problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 1169 Lines: 30 Background: I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon. The kernel that comes with the board is 2.4.18 with an embedded ramdisk that runs some scripts to install RPMS via NFS or CD-ROM. The kernel is converted to s-records via objcopy(1), and loaded into memory via tftp. I want to do something similar with 2.6.latest. Problem: On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared. http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html In it's place it is suggested to use the tools in arch/mips/boot, so I tried it. I can cross-compile the kernel, and I get an ELF vmlinux. I can convert it to ecoff with elf2ecoff, and attach an initrd image with addinitrd. The problem begins here. I end up with an ecoff format kernel which is not recognized by objcopy(1), and therefore no s-records. It seems there is a program called gensrec that would do the job, but google doesn't want to tell me where to get it. Some IRIX binary perhaps? Solution? Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or write an ELF version of addinitrd? Other ideas? Thanks in advance. From kumba@gentoo.org Fri Mar 11 00:41:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 00:42:03 +0000 (GMT) Received: from sccrmhc14.comcast.net ([IPv6:::ffff:204.127.202.59]:16847 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 00:41:46 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (sccrmhc14) with ESMTP id <2005031100413901400pqdfpe>; Fri, 11 Mar 2005 00:41:40 +0000 Message-ID: <4230E940.2000202@gentoo.org> Date: Thu, 10 Mar 2005 19:41:36 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Martini , linux-mips@linux-mips.org, Steve Stone Subject: Re: initrd problem References: <4230DB4C.7090103@c2micro.com> In-Reply-To: <4230DB4C.7090103@c2micro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 2225 Lines: 53 Ed Martini wrote: > Background: > > I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon. The > kernel that comes with the board is 2.4.18 with an embedded ramdisk that > runs some scripts to install RPMS via NFS or CD-ROM. The kernel is > converted to s-records via objcopy(1), and loaded into memory via tftp. > I want to do something similar with 2.6.latest. > > Problem: > > On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared. > > http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html > > In it's place it is suggested to use the tools in arch/mips/boot, so I > tried it. I can cross-compile the kernel, and I get an ELF vmlinux. I > can convert it to ecoff with elf2ecoff, and attach an initrd image with > addinitrd. The problem begins here. I end up with an ecoff format > kernel which is not recognized by objcopy(1), and therefore no s-records. > > It seems there is a program called gensrec that would do the job, but > google doesn't want to tell me where to get it. Some IRIX binary perhaps? > > Solution? > > Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or > write an ELF version of addinitrd? Other ideas? > > Thanks in advance. The future is purportedly in the feature known as initramfs. See the file Documentation/early-userpace/README for more details on how that is supposed to work. That said, I tried initramfs a few times, but either due to lack of understanding, or broken support code in 2.6.10, I couldn't get it to properly load an initrd bundled in, so I forward-ported a patch I wrote that originally fixed CONFIG_EMBEDDED_RAMDISK to work with any ABI to 2.6.10, and it worked rather well. I'm sticking with this method until I find more/better docs on how to use initramfs properly. If you're interested, the patch I use can be found here: http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.10-add-ramdisk-back.patch [2.6.10] http://dev.gentoo.org/~kumba/mips/misc/misc-2.6.11-add-ramdisk-back.patch [2.6.11] --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From mailinglist.linux@gmail.com Fri Mar 11 01:46:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 01:46:44 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.198]:50420 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 01:46:29 +0000 Received: by wproxy.gmail.com with SMTP id 37so607632wra for ; Thu, 10 Mar 2005 17:46:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GIy2VN/LXn7g//is6gQwVltlaG0pRtbKsKXuIazKUacSasIhaO8NnLeJjbBFRaGfnc/3fPjSpmjCVQxktChrmcLdjPfMR9GHwvWuG8UanTTH6GPSVvoIhj/sOcVCDy7r+SJYbFgho4IuyMv7Z3KXX0A7yz/gCVS5/1JMVw0+4ZQ= Received: by 10.54.65.13 with SMTP id n13mr964628wra; Thu, 10 Mar 2005 17:46:23 -0800 (PST) Received: by 10.54.56.8 with HTTP; Thu, 10 Mar 2005 17:46:23 -0800 (PST) Message-ID: <77fd3fe00503101746fed176b@mail.gmail.com> Date: Thu, 10 Mar 2005 17:46:23 -0800 From: Linux Mailinglist Reply-To: Linux Mailinglist To: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! In-Reply-To: <20050309173044.GA18688@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mailinglist.linux@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 529 Lines: 20 Hi Ralf ! Thanks, but the problem with this SOC is that it does not have MMU. I would like to know wheather we have the port for Mips 4Km processor without MMU ? Thanks in advance. Srinivasan On Wed, 9 Mar 2005 17:30:44 +0000, Ralf Baechle wrote: > On Tue, Mar 08, 2005 at 08:26:40PM -0800, Linux Mailinglist wrote: > > > Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 processor ? > > That's not a processor but a whole SOC and the processor is a 4Km which > is supported. > > Ralf > From ppopov@embeddedalley.com Fri Mar 11 01:56:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 01:56:44 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:32527 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 01:56:29 +0000 Received: from [10.1.100.4] ([64.164.196.27]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j2B1tuX5024249; Thu, 10 Mar 2005 20:55:56 -0500 Message-ID: <4230FAC9.6040304@embeddedalley.com> Date: Thu, 10 Mar 2005 17:56:25 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com MIME-Version: 1.0 To: Linux Mailinglist CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> <77fd3fe00503101746fed176b@mail.gmail.com> In-Reply-To: <77fd3fe00503101746fed176b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 703 Lines: 33 Linux Mailinglist wrote: > Hi Ralf ! > > Thanks, but the problem with this SOC is that it does not have MMU. I > would like to know wheather we have the port for Mips 4Km processor > without MMU ? Take a look at uclinux.org. That's the MMU-less project. I don't know what the MIPS statis is though. Pete > > Thanks in advance. > Srinivasan > > > On Wed, 9 Mar 2005 17:30:44 +0000, Ralf Baechle wrote: > >>On Tue, Mar 08, 2005 at 08:26:40PM -0800, Linux Mailinglist wrote: >> >> >>>Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 processor ? >> >>That's not a processor but a whole SOC and the processor is a 4Km which >>is supported. >> >> Ralf >> > > > From mlachwani@mvista.com Fri Mar 11 02:14:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 02:14:23 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:17658 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 02:14:08 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id A9E2018BA1; Thu, 10 Mar 2005 18:14:05 -0800 (PST) Message-ID: <4230FEED.9090402@mvista.com> Date: Thu, 10 Mar 2005 18:14:05 -0800 From: Manish Lachwani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ppopov@embeddedalley.com Cc: Linux Mailinglist , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> <77fd3fe00503101746fed176b@mail.gmail.com> <4230FAC9.6040304@embeddedalley.com> In-Reply-To: <4230FAC9.6040304@embeddedalley.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mlachwani@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 861 Lines: 50 Hello ! 4Km is a 4Kc without TLB. I think this is supported. Thanks Manish Lachwani Pete Popov wrote: > Linux Mailinglist wrote: > >> Hi Ralf ! >> >> Thanks, but the problem with this SOC is that it does not have MMU. I >> would like to know wheather we have the port for Mips 4Km processor >> without MMU ? > > > Take a look at uclinux.org. That's the MMU-less project. I don't know > what the MIPS statis is though. > > Pete > >> >> Thanks in advance. Srinivasan >> >> >> On Wed, 9 Mar 2005 17:30:44 +0000, Ralf Baechle >> wrote: >> >>> On Tue, Mar 08, 2005 at 08:26:40PM -0800, Linux Mailinglist wrote: >>> >>> >>>> Is anybody have a port of Linux 2.6 kernel on Brecis MSP2100 >>>> processor ? >>> >>> >>> That's not a processor but a whole SOC and the processor is a 4Km which >>> is supported. >>> >>> Ralf >>> >> >> >> > > From Rishabh@soc-soft.com Fri Mar 11 05:23:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 05:25:32 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:49671 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 05:23:56 +0000 Received: from soc-mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Fri, 11 Mar 2005 10:55:44 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C525FA.C5C0374C" Subject: Memory Management HAndling X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 11 Mar 2005 10:55:43 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Memory Management HAndling Thread-Index: AcUl+sVNe6ILwKERTZi7nowQqUqIeQ== From: To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rishabh@soc-soft.com Precedence: bulk X-list: linux-mips Content-Length: 2454 Lines: 68 This is a multi-part message in MIME format. ------_=_NextPart_001_01C525FA.C5C0374C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have been working on MMU of Linux Port of 2.4.20 kernel for MIPS Port. I have found that MACROS like=0D #define __pa(x) ((unsigned long) (x) - PAGE_OFFSET) #define __va(x) ((void *)((unsigned long) (x) + PAGE_OFFSET)) #define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT)) These macros can handle memory pages in KSEG0. Any suggestions on how can they be changed for addressing memory present in HIGHMEM. Since VA will not be in linear relation with mem_map.=0D Rishabh Kumar Goel Software Engineer =0D SoCrates Software India Pvt. Ltd. a TOSHIBA Group Company #10, Industrial Layout, Prestige Atlanta, III Block, Koramangala, Bangalore - 560034 =0D Ph. 080-51101669 The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If= you are not the intended recipient, please notify the sender and delete the message= along with any annexure. You should not disclose, copy or otherwise use the= information contained in the message or any annexure. Any views expressed in this e-mail are= those of the individual sender except where the sender specifically states them to be= the views of SoCrates Software India Pvt Ltd., Bangalore. ------_=_NextPart_001_01C525FA.C5C0374C Content-Type: text/x-vcard; name="Rishabh Kumar Goel.vcf" Content-Transfer-Encoding: base64 Content-Description: Rishabh Kumar Goel.vcf Content-Disposition: attachment; filename="Rishabh Kumar Goel.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkdvZWw7UmlzaGFiaCBLdW1hcg0KRk46UmlzaGFi aCBLdW1hciBHb2VsDQpPUkc6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0IEx0ZC47T1MgJiBE RA0KVElUTEU6U0UNClRFTDtXT1JLO1ZPSUNFOjUxMTAxNjY5ICAgIEV4dDoyNjY5DQpBRFI7V09S SztFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOjtTb2NyYXRlcyBTb2Z0d2FyZSBJbmRpYSBQdnQu IEx0ZC47MTAgQnJpZGUgU3RyZWV0LCA9MEQ9MEFMYW5nZm9yZCBUb3duO0Jhbmc9DQphbG9yZTtL YXJuYXRha2E7NTYwMDI1O0lORElBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFC TEU6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0LiBMdGQuPTBEPTBBMTAgQnJpZGUgU3RyZWV0 LCA9MEQ9MEFMYW5nZm9yZCBUb3duPQ0KPTBEPTBBQmFuZ2Fsb3JlLCBLYXJuYXRha2EgNTYwMDI1 PTBEPTBBSU5ESUENCkVNQUlMO1BSRUY7SU5URVJORVQ6UmlzaGFiaEBzb2Mtc29mdC5jb20NClJF VjoyMDA1MDIxN1QwNjA4NDJaDQpFTkQ6VkNBUkQNCg== ------_=_NextPart_001_01C525FA.C5C0374C-- From alan@lxorguk.ukuu.org.uk Fri Mar 11 13:38:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 13:38:33 +0000 (GMT) Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:55959 "EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 13:38:18 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j2BDaYn2018203; Fri, 11 Mar 2005 13:36:34 GMT Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j2BDaW4N018202; Fri, 11 Mar 2005 13:36:32 GMT X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Memory Management HAndling From: Alan Cox To: Rishabh@soc-soft.com Cc: linux-mips@linux-mips.org In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> References: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1110548190.15943.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 11 Mar 2005 13:36:31 +0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 321 Lines: 7 On Gwe, 2005-03-11 at 05:25, Rishabh@soc-soft.com wrote: > These macros can handle memory pages in KSEG0. Any suggestions on how > can they be changed for addressing memory present in HIGHMEM. Since VA > will not be in linear relation with mem_map. Take a look at how kmap() works on x86 and how the mappings are used. From ralf@linux-mips.org Fri Mar 11 14:35:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 14:35:51 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:57355 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 14:35:30 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2BEZ3EE006193; Fri, 11 Mar 2005 14:35:03 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2BEZ2R5006192; Fri, 11 Mar 2005 14:35:02 GMT Date: Fri, 11 Mar 2005 14:35:02 +0000 From: Ralf Baechle To: Manish Lachwani Cc: ppopov@embeddedalley.com, Linux Mailinglist , linux-mips@linux-mips.org Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! Message-ID: <20050311143502.GB5958@linux-mips.org> References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> <77fd3fe00503101746fed176b@mail.gmail.com> <4230FAC9.6040304@embeddedalley.com> <4230FEED.9090402@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4230FEED.9090402@mvista.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 445 Lines: 12 On Thu, Mar 10, 2005 at 06:14:05PM -0800, Manish Lachwani wrote: > 4Km is a 4Kc without TLB. I think this is supported. Maybe at uclinux.org but certainly not on linux-mips.org. There have never been many requests for Linux on TLB-less processors and in recent years the interest that low interest seems to have fallen even further. That said, if anybody wants to working on supporting MIPS with CONFIG_MMU=n by all means, go ahead. Ralf From ralf@linux-mips.org Fri Mar 11 15:58:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 15:58:59 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:25622 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 15:58:45 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2BFwPxn009257; Fri, 11 Mar 2005 15:58:25 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2BFwOpp009255; Fri, 11 Mar 2005 15:58:24 GMT Date: Fri, 11 Mar 2005 15:58:23 +0000 From: Ralf Baechle To: Rishabh@soc-soft.com Cc: linux-mips@linux-mips.org Subject: Re: Memory Management HAndling Message-ID: <20050311155823.GC5958@linux-mips.org> References: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 746 Lines: 21 On Fri, Mar 11, 2005 at 10:55:43AM +0530, Rishabh@soc-soft.com wrote: > I have been working on MMU of Linux Port of 2.4.20 kernel for MIPS Port. You may want to change to a kernel that has less than 52 months worth of bugs and security holes. > I have found that MACROS like > > #define __pa(x) ((unsigned long) (x) - PAGE_OFFSET) > #define __va(x) ((void *)((unsigned long) (x) + PAGE_OFFSET)) > #define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT)) > > > These macros can handle memory pages in KSEG0. Any suggestions on how > can they be changed for addressing memory present in HIGHMEM. Since VA > will not be in linear relation with mem_map. That's normal for highmem. These macros will only work for lowmem. Ralf From ralf@linux-mips.org Fri Mar 11 15:59:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 15:59:58 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:31253 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 15:59:43 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2BFxOYk009274; Fri, 11 Mar 2005 15:59:24 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2BFxOij009273; Fri, 11 Mar 2005 15:59:24 GMT Date: Fri, 11 Mar 2005 15:59:24 +0000 From: Ralf Baechle To: Alan Cox Cc: Rishabh@soc-soft.com, linux-mips@linux-mips.org Subject: Re: Memory Management HAndling Message-ID: <20050311155924.GD5958@linux-mips.org> References: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> <1110548190.15943.46.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110548190.15943.46.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 452 Lines: 12 On Fri, Mar 11, 2005 at 01:36:31PM +0000, Alan Cox wrote: > On Gwe, 2005-03-11 at 05:25, Rishabh@soc-soft.com wrote: > > These macros can handle memory pages in KSEG0. Any suggestions on how > > can they be changed for addressing memory present in HIGHMEM. Since VA > > will not be in linear relation with mem_map. > > Take a look at how kmap() works on x86 and how the mappings are used. Highmem is supported for MIPS since ~ 2.4.18 or so. Ralf From mlachwani@mvista.com Fri Mar 11 17:06:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 17:07:02 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44530 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 17:06:47 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 894FF18A0B; Fri, 11 Mar 2005 09:06:42 -0800 (PST) Message-ID: <4231D022.9050604@mvista.com> Date: Fri, 11 Mar 2005 09:06:42 -0800 From: Manish Lachwani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle Cc: Alan Cox , Rishabh@soc-soft.com, linux-mips@linux-mips.org Subject: Re: Memory Management HAndling References: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> <1110548190.15943.46.camel@localhost.localdomain> <20050311155924.GD5958@linux-mips.org> In-Reply-To: <20050311155924.GD5958@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mlachwani@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 657 Lines: 30 Ralf Baechle wrote: >On Fri, Mar 11, 2005 at 01:36:31PM +0000, Alan Cox wrote: > > > >>On Gwe, 2005-03-11 at 05:25, Rishabh@soc-soft.com wrote: >> >> >>>These macros can handle memory pages in KSEG0. Any suggestions on how >>>can they be changed for addressing memory present in HIGHMEM. Since VA >>>will not be in linear relation with mem_map. >>> >>> >>Take a look at how kmap() works on x86 and how the mappings are used. >> >> > >Highmem is supported for MIPS since ~ 2.4.18 or so. > > Ralf > > > Right, I had the 2.4.21 HIGHMEM working on PMC-Sierra Yosemite. Also, at that time, Sibyte supported HIGHMEM. Thanks Manish Lachwani From ralf@linux-mips.org Fri Mar 11 17:22:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 17:23:14 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:18974 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 17:22:49 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2BHMT2F011803; Fri, 11 Mar 2005 17:22:29 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2BHMSrb011802; Fri, 11 Mar 2005 17:22:28 GMT Date: Fri, 11 Mar 2005 17:22:28 +0000 From: Ralf Baechle To: Manish Lachwani Cc: Alan Cox , Rishabh@soc-soft.com, linux-mips@linux-mips.org Subject: Re: Memory Management HAndling Message-ID: <20050311172228.GA6407@linux-mips.org> References: <4BF47D56A0DD2346A1B8D622C5C5902C61E22B@soc-mail.soc-soft.com> <1110548190.15943.46.camel@localhost.localdomain> <20050311155924.GD5958@linux-mips.org> <4231D022.9050604@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4231D022.9050604@mvista.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 254 Lines: 8 On Fri, Mar 11, 2005 at 09:06:42AM -0800, Manish Lachwani wrote: > Right, I had the 2.4.21 HIGHMEM working on PMC-Sierra Yosemite. Also, at > that time, Sibyte supported HIGHMEM. It's going to work for any CPU that doesn't have cache aliases. Ralf From mailinglist.linux@gmail.com Fri Mar 11 18:26:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Mar 2005 18:26:33 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.199]:56410 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Fri, 11 Mar 2005 18:26:17 +0000 Received: by wproxy.gmail.com with SMTP id 37so765328wra for ; Fri, 11 Mar 2005 10:26:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZFNftM3Tyk10cH01geGk/FYd+mL79AoYhkhMN1dlacCwt8zIFNL67EBzDIp03kueW6qYwj+3cNlDOWOPu1MS7CXlag1xIdJpMF4t4Xu3WurYOZHSOJECLJxdCbkgrFzFDVhi1hLGJvtS9utchxpKdsOaYHm8/+KOrEHD7wYLpL4= Received: by 10.54.49.36 with SMTP id w36mr1279795wrw; Fri, 11 Mar 2005 10:26:11 -0800 (PST) Received: by 10.54.56.8 with HTTP; Fri, 11 Mar 2005 10:26:11 -0800 (PST) Message-ID: <77fd3fe005031110261fd30c29@mail.gmail.com> Date: Fri, 11 Mar 2005 10:26:11 -0800 From: Linux Mailinglist Reply-To: Linux Mailinglist To: Ralf Baechle Subject: Re: Linux 2.6 support for Brecis MSP2100 processor ! Cc: Manish Lachwani , ppopov@embeddedalley.com, linux-mips@linux-mips.org In-Reply-To: <20050311143502.GB5958@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <77fd3fe0050308202654a4432a@mail.gmail.com> <20050309173044.GA18688@linux-mips.org> <77fd3fe00503101746fed176b@mail.gmail.com> <4230FAC9.6040304@embeddedalley.com> <4230FEED.9090402@mvista.com> <20050311143502.GB5958@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mailinglist.linux@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 635 Lines: 19 Thanks everiybody. I think I should go ahead and start doing it myself. Srinivasan On Fri, 11 Mar 2005 14:35:02 +0000, Ralf Baechle wrote: > On Thu, Mar 10, 2005 at 06:14:05PM -0800, Manish Lachwani wrote: > > > 4Km is a 4Kc without TLB. I think this is supported. > > Maybe at uclinux.org but certainly not on linux-mips.org. There have never > been many requests for Linux on TLB-less processors and in recent years > the interest that low interest seems to have fallen even further. > > That said, if anybody wants to working on supporting MIPS with > CONFIG_MMU=n by all means, go ahead. > > Ralf > From anemo@mba.ocn.ne.jp Mon Mar 14 06:58:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Mar 2005 06:59:03 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:47620 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Mon, 14 Mar 2005 06:58:47 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 14 Mar 2005 06:58:45 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 8069B1F1DF; Mon, 14 Mar 2005 15:58:41 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 6BF121F1DE; Mon, 14 Mar 2005 15:58:41 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j2E6we9c036604; Mon, 14 Mar 2005 15:58:41 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 14 Mar 2005 15:58:40 +0900 (JST) Message-Id: <20050314.155840.44100135.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: multi-threaded core dump From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1537 Lines: 41 It seems linux-mips does not produce correct register dumps in core file for multi-threaded programs. This patch tries to fix it. Could you review it? Thank you. diff -ur linux-mips/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c --- linux-mips/arch/mips/kernel/process.c 2005-03-04 10:19:33.000000000 +0900 +++ linux/arch/mips/kernel/process.c 2005-03-14 15:51:43.592837356 +0900 @@ -167,6 +167,14 @@ #endif } +int dump_task_regs (struct task_struct *tsk, elf_gregset_t *regs) +{ + struct thread_info *ti = tsk->thread_info; + long ksp = (unsigned long)ti + THREAD_SIZE - 32; + dump_regs(&(*regs)[0], (struct pt_regs *) ksp - 1); + return 1; +} + int dump_task_fpu (struct task_struct *t, elf_fpregset_t *fpr) { memcpy(fpr, &t->thread.fpu, sizeof(current->thread.fpu)); diff -ur linux-mips/include/asm-mips/elf.h linux/include/asm-mips/elf.h --- linux-mips/include/asm-mips/elf.h 2005-03-04 10:19:35.000000000 +0900 +++ linux/include/asm-mips/elf.h 2005-03-14 15:52:22.000046107 +0900 @@ -225,10 +225,12 @@ #endif /* CONFIG_MIPS64 */ extern void dump_regs(elf_greg_t *, struct pt_regs *regs); +extern int dump_task_regs (struct task_struct *, elf_gregset_t *); extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *); #define ELF_CORE_COPY_REGS(elf_regs, regs) \ dump_regs((elf_greg_t *)&(elf_regs), regs); +#define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk, elf_regs) #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) \ dump_task_fpu(tsk, elf_fpregs) --- Atsushi Nemoto From ralf@linux-mips.org Mon Mar 14 10:19:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Mar 2005 10:19:27 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:16154 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 14 Mar 2005 10:19:12 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2EAITQG009285; Mon, 14 Mar 2005 10:18:29 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2EAISKL009284; Mon, 14 Mar 2005 10:18:28 GMT Date: Mon, 14 Mar 2005 10:18:28 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: multi-threaded core dump Message-ID: <20050314101828.GA7759@linux-mips.org> References: <20050314.155840.44100135.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050314.155840.44100135.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 263 Lines: 9 On Mon, Mar 14, 2005 at 03:58:40PM +0900, Atsushi Nemoto wrote: > It seems linux-mips does not produce correct register dumps in core > file for multi-threaded programs. This patch tries to fix it. Could > you review it? Thank you. Thanks, applied. Ralf From ralf@linux-mips.org Mon Mar 14 11:02:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Mar 2005 11:02:16 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:6161 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 14 Mar 2005 11:02:01 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2EB11Im017065; Mon, 14 Mar 2005 11:01:01 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2EB11RB017064; Mon, 14 Mar 2005 11:01:01 GMT Date: Mon, 14 Mar 2005 11:01:01 +0000 From: Ralf Baechle To: Ed Martini Cc: linux-mips@linux-mips.org, Steve Stone Subject: Re: initrd problem Message-ID: <20050314110101.GF7759@linux-mips.org> References: <4230DB4C.7090103@c2micro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4230DB4C.7090103@c2micro.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1495 Lines: 34 On Thu, Mar 10, 2005 at 03:42:04PM -0800, Ed Martini wrote: > I'm trying to get 2.6.11 to run on a MIPS Malta board with Yamon. The > kernel that comes with the board is 2.4.18 with an embedded ramdisk that > runs some scripts to install RPMS via NFS or CD-ROM. The kernel is > converted to s-records via objcopy(1), and loaded into memory via tftp. > I want to do something similar with 2.6.latest. > > Problem: > > On or about Nov 21 of last year, the CONFIG_EMBEDDED_RAMDISK disappeared. > > http://www.linux-mips.org/archives/linux-mips/2004-11/msg00135.html > > In it's place it is suggested to use the tools in arch/mips/boot, so I > tried it. I can cross-compile the kernel, and I get an ELF vmlinux. I > can convert it to ecoff with elf2ecoff, and attach an initrd image with > addinitrd. The problem begins here. I end up with an ecoff format > kernel which is not recognized by objcopy(1), and therefore no s-records. I guess that was an act of desperation - YAMON needs SRECs to be happy but doesn't know anything about SRECs. > It seems there is a program called gensrec that would do the job, but > google doesn't want to tell me where to get it. Some IRIX binary perhaps? make vmlinux.srec; the resulting file will be in arch/mips/boot/vmlinux.srec. > Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or > write an ELF version of addinitrd? Other ideas? Things vanish for a reason ... Try CONFIG_INITRAMFS_SOURCE instead. Ralf From eckhardt@satorlaser.com Tue Mar 15 07:31:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 07:32:01 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.184]:5108 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 07:31:45 +0000 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DB6Wa-00033u-00; Tue, 15 Mar 2005 08:31:32 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DB6Wa-0008Hg-00; Tue, 15 Mar 2005 08:31:32 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] fix structure declarations Date: Tue, 15 Mar 2005 08:30:23 +0100 User-Agent: KMail/1.7.1 Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503150830.23760.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1082 Lines: 46 Hi! Seems someone went about adding C99 initialisers, but accidentally 'fixed' these structure definitions containing bitfields... Uli Index: drivers/pcmcia/au1000_generic.h =================================================================== RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.h,v retrieving revision 1.5 diff -u -r1.5 au1000_generic.h --- drivers/pcmcia/au1000_generic.h 28 Feb 2005 13:35:57 -0000 1.5 +++ drivers/pcmcia/au1000_generic.h 15 Mar 2005 07:27:41 -0000 @@ -61,21 +61,21 @@ struct pcmcia_state { unsigned detect: 1, - .ready = 1, - .wrprot = 1, - bvd1: 1, - bvd2: 1, + ready: 1, + wrprot: 1, + bvd1: 1, + bvd2: 1, vs_3v: 1, vs_Xv: 1; }; struct pcmcia_configure { unsigned sock: 8, - .vcc = 8, - .vpp = 8, - .output = 1, - .speaker = 1, - .reset = 1; + vcc: 8, + vpp: 8, + output: 1, + speaker: 1, + reset: 1; }; struct pcmcia_irqs { From eckhardt@satorlaser.com Tue Mar 15 11:45:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 11:45:39 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.177]:13051 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 11:45:23 +0000 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DBAUB-0005UL-00 for linux-mips@linux-mips.org; Tue, 15 Mar 2005 12:45:19 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DBAUB-0001Xw-00 for linux-mips@linux-mips.org; Tue, 15 Mar 2005 12:45:20 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: need help with CompactFlash/PCMCIA Date: Tue, 15 Mar 2005 12:45:15 +0100 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503151245.15920.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1737 Lines: 52 Hi! I have a board here which roughly resembles a DB1100, AFAICT. My problem is that I can't get the CompactFlash card to be recognized, and I don't even know where exactly it fails. So, a few questions up front: 1. CompactFlash is accessed via PCMCIA, it does not use the MTD infrastructure, right? I also read that the CF then appears as a normal(?) ATA device. So, what should be the right drivers for it? 2. How can I find out if it's looking at the right addresses? I just need some kind of register which I can probe to find out if the device is where I think it should be. Hmm, in fact I'd be happy about _any_ hint the would get me further. I'm slightly desparate... Appended is a patch that removes an unused variable, something I found while trying to understand what's going on there. thanks Uli --- Index: au1000_generic.c =================================================================== RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.c,v retrieving revision 1.18 diff -u -r1.18 au1000_generic.c --- au1000_generic.c 25 Jan 2005 04:28:38 -0000 1.18 +++ au1000_generic.c 15 Mar 2005 11:40:26 -0000 @@ -66,10 +66,6 @@ #define PCMCIA_SOCKET(x) (au1000_pcmcia_socket + (x)) #define to_au1000_socket(x) container_of(x, struct au1000_pcmcia_socket, socket) -/* Some boards like to support CF cards as IDE root devices, so they - * grab pcmcia sockets directly. - */ -u32 *pcmcia_base_vaddrs[2]; extern const unsigned long mips_io_port_base; DECLARE_MUTEX(pcmcia_sockets_lock); @@ -437,7 +433,6 @@ skt->phys_mem = AU1X_SOCK1_PSEUDO_PHYS_MEM; } #endif - pcmcia_base_vaddrs[i] = (u32 *)skt->virt_io; ret = ops->hw_init(skt); skt->socket.features = SS_CAP_STATIC_MAP|SS_CAP_PCCARD; From ralf@linux-mips.org Tue Mar 15 12:56:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 12:56:21 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:13339 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 12:56:07 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2FCtHCS007092; Tue, 15 Mar 2005 12:55:17 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2FCtH56007091; Tue, 15 Mar 2005 12:55:17 GMT Date: Tue, 15 Mar 2005 12:55:17 +0000 From: Ralf Baechle To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org Subject: Re: [patch] fix structure declarations Message-ID: <20050315125517.GD6025@linux-mips.org> References: <200503150830.23760.eckhardt@satorlaser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503150830.23760.eckhardt@satorlaser.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 258 Lines: 6 On Tue, Mar 15, 2005 at 08:30:23AM +0100, Ulrich Eckhardt wrote: > Seems someone went about adding C99 initialisers, but accidentally 'fixed' > these structure definitions containing bitfields... Your mailer converted the tabs in the patch into spaces .. From brad@laronde.org Tue Mar 15 14:04:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 14:04:40 +0000 (GMT) Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:40411 "EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 14:04:22 +0000 Received: from lahoo.priv ([69.40.149.179]) by ispmxmta09-srv.alltel.net with ESMTP id <20050315140408.SLWN4937.ispmxmta09-srv.alltel.net@lahoo.priv> for ; Tue, 15 Mar 2005 08:04:08 -0600 Received: from [10.1.1.128] (helo=prefect) by lahoo.priv with smtp (Exim 4.44) id 1DBCYq-0002pN-2B for linux-mips@linux-mips.org; Tue, 15 Mar 2005 08:58:16 -0500 Message-ID: <006601c52967$94040970$8001010a@prefect> From: "Bradley D. LaRonde" To: Subject: Tabs in message headers? Date: Tue, 15 Mar 2005 09:01:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips Content-Length: 172 Lines: 7 Did messages from the list all of a sudden get tabs (instead of spaces) in the message headers? Had to adjust my (probably too specific) procmail rule. Regards, Brad From D.Mierzejewski@icm.edu.pl Tue Mar 15 14:11:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 14:12:00 +0000 (GMT) Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:14218 "EHLO atol.icm.edu.pl") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 14:11:45 +0000 Received: from fs.icm.edu.pl (fs.icm.edu.pl [192.168.1.165]) by atol.icm.edu.pl (8.13.1/8.13.1/rzm-5.1/icm) with ESMTP id j2FEBgOY021751 for ; Tue, 15 Mar 2005 15:11:43 +0100 Received: from koral.icm.edu.pl (koral.icm.edu.pl [192.168.1.219]) by fs.icm.edu.pl (8.13.3/8.13.2/rzm-2.9.4/icm) with ESMTP id j2FEBcWG025650 for ; Tue, 15 Mar 2005 15:11:38 +0100 (CET) Received: by koral.icm.edu.pl (Postfix, from userid 5242) id 9E78EAE0001; Tue, 15 Mar 2005 15:11:46 +0100 (CET) Date: Tue, 15 Mar 2005 15:11:46 +0100 From: "Dominik 'Rathann' Mierzejewski" To: linux-mips@linux-mips.org Subject: Re: Tabs in message headers? Message-ID: <20050315141146.GE4871@koral.icm.edu.pl> Mail-Followup-To: linux-mips@linux-mips.org References: <006601c52967$94040970$8001010a@prefect> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006601c52967$94040970$8001010a@prefect> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: D.Mierzejewski@icm.edu.pl Precedence: bulk X-list: linux-mips Content-Length: 527 Lines: 12 On Tue, Mar 15, 2005 at 09:01:38AM -0500, Bradley D. LaRonde wrote: > Did messages from the list all of a sudden get tabs (instead of spaces) in > the message headers? Had to adjust my (probably too specific) procmail > rule. They've always been spaces, at least as long as I've been subscribed (which is about 1.5 years). -- Dominik 'Rathann' Mierzejewski Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810 From ralf@linux-mips.org Tue Mar 15 14:36:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 14:36:42 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:37653 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 14:36:27 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2FEZ3sl010343; Tue, 15 Mar 2005 14:35:03 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2FEZ2Ju010342; Tue, 15 Mar 2005 14:35:02 GMT Date: Tue, 15 Mar 2005 14:35:02 +0000 From: Ralf Baechle To: "Bradley D. LaRonde" Cc: linux-mips@linux-mips.org Subject: Re: Tabs in message headers? Message-ID: <20050315143502.GE6025@linux-mips.org> References: <006601c52967$94040970$8001010a@prefect> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006601c52967$94040970$8001010a@prefect> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 465 Lines: 12 On Tue, Mar 15, 2005 at 09:01:38AM -0500, Bradley D. LaRonde wrote: > Did messages from the list all of a sudden get tabs (instead of spaces) in > the message headers? Had to adjust my (probably too specific) procmail > rule. Linux-mips.org is running zmailer which by default has the habit of generating headers containing tabs and it's doing so since the machine exists so something on the way from linux-mips.org to your procmail must have changed. Ralf From ppopov@embeddedalley.com Tue Mar 15 17:31:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 17:32:04 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:65039 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 17:31:47 +0000 Received: from [10.1.100.4] ([64.164.196.27]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j2FHUhPt014943; Tue, 15 Mar 2005 12:30:44 -0500 Message-ID: <42371C05.7060401@embeddedalley.com> Date: Tue, 15 Mar 2005 09:31:49 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA References: <200503151245.15920.eckhardt@satorlaser.com> In-Reply-To: <200503151245.15920.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 2469 Lines: 74 Ulrich Eckhardt wrote: > Hi! > > I have a board here which roughly resembles a DB1100, AFAICT. My problem is > that I can't get the CompactFlash card to be recognized, and I don't even > know where exactly it fails. > So, a few questions up front: > 1. CompactFlash is accessed via PCMCIA, it does not use the MTD > infrastructure, right? Correct. > I also read that the CF then appears as a normal(?) > ATA device. So, what should be the right drivers for it? The au1x00_ss socket driver, the pcmcia stack modules or statically compiled, and ide-cs.o, which is the pcmcia ide client driver. > 2. How can I find out if it's looking at the right addresses? I just need some > kind of register which I can probe to find out if the device is where I think > it should be. > > Hmm, in fact I'd be happy about _any_ hint the would get me further. I'm > slightly desparate... Start with the low level routines that detect the card and set the voltage levels. When you plug in the card, is it detected? Are you setting the correct voltages? What happens next -- is the card at least recognized by the cardmgr, which means that the attribute memory is read correctly? > Appended is a patch that removes an unused variable, something I found while > trying to understand what's going on there. Well, there is another patch for a custom board that uses those unused variables. Perhaps those variables should just be part of that external patch... Pete > thanks > > Uli > > --- > > Index: au1000_generic.c > =================================================================== > RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.c,v > retrieving revision 1.18 > diff -u -r1.18 au1000_generic.c > --- au1000_generic.c 25 Jan 2005 04:28:38 -0000 1.18 > +++ au1000_generic.c 15 Mar 2005 11:40:26 -0000 > @@ -66,10 +66,6 @@ > #define PCMCIA_SOCKET(x) (au1000_pcmcia_socket + (x)) > #define to_au1000_socket(x) container_of(x, struct au1000_pcmcia_socket, > socket) > > -/* Some boards like to support CF cards as IDE root devices, so they > - * grab pcmcia sockets directly. > - */ > -u32 *pcmcia_base_vaddrs[2]; > extern const unsigned long mips_io_port_base; > > DECLARE_MUTEX(pcmcia_sockets_lock); > @@ -437,7 +433,6 @@ > skt->phys_mem = AU1X_SOCK1_PSEUDO_PHYS_MEM; > } > #endif > - pcmcia_base_vaddrs[i] = (u32 *)skt->virt_io; > ret = ops->hw_init(skt); > > skt->socket.features = SS_CAP_STATIC_MAP|SS_CAP_PCCARD; > > From maillist@jg555.com Tue Mar 15 21:40:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 21:40:28 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:44267 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 21:40:12 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 15 Mar 2005 13:40:10 -0800 id 0000C3B4.4237563A.0000258A Message-ID: <42375617.3020002@jg555.com> Date: Tue, 15 Mar 2005 13:39:35 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: Current Build Warning Message Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 297 Lines: 13 I just tried doing a current build on a 2.6.11 systems. I get the following warnings. *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined! Any ideas on how to correct this? -- ---- Jim Gifford maillist@jg555.com From martini@c2micro.com Tue Mar 15 22:39:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Mar 2005 22:39:56 +0000 (GMT) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:60299 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Tue, 15 Mar 2005 22:39:40 +0000 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id 5D3E825C95F for ; Tue, 15 Mar 2005 14:39:37 -0800 (PST) Message-ID: <423763B9.2000907@c2micro.com> Date: Tue, 15 Mar 2005 14:37:45 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: initrd problem References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> In-Reply-To: <20050314110101.GF7759@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 2264 Lines: 76 Ralf Baechle wrote: >On Thu, Mar 10, 2005 at 03:42:04PM -0800, Ed Martini wrote: > > >>Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or >>write an ELF version of addinitrd? Other ideas? >> >> > >Things vanish for a reason ... Try CONFIG_INITRAMFS_SOURCE instead. > > Ralf > Ok. Then let's get rid of it completly, and provide a replacement that works. There were vestiges of embedded initrd in the ld script that were confusing when trying to sort things out. That, in conjunction with Documentation/initrd.txt made it hard to discover early user space and initramfs when coming from the old world (2.4). Also, unless you move the location of .init.ramfs, it gets freed twice, leading to a panic. From the documentation alone it's impossible to figure out how to build your initramfs. In various places the docs refer to the initial executable as /linuxrc, /kinit, /init, and possibly others. If you read init/main.c you see that for an initramfs, your initial process will be started from /init. diff -urN linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S linux/arch/mips/kernel/vmlinux.lds.S --- linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S 2005-03-15 13:41:51.000000000 -0800 +++ linux/arch/mips/kernel/vmlinux.lds.S 2005-03-15 14:34:00.339164936 -0800 @@ -54,13 +54,6 @@ *(.data) - /* Align the initial ramdisk image (INITRD) on page boundaries. */ - . = ALIGN(4096); - __rd_start = .; - *(.initrd) - . = ALIGN(4096); - __rd_end = .; - CONSTRUCTORS } _gp = . + 0x8000; @@ -82,6 +75,13 @@ _edata = .; /* End of data section */ + /* Align the initial ramfs image on page boundaries. */ + /* It will be freed by init/initramfs.c */ + . = ALIGN(4096); + __initramfs_start = .; + .init.ramfs : { *(.init.ramfs) } + __initramfs_end = .; + /* will be freed after init */ . = ALIGN(4096); /* Init code and data */ __init_begin = .; @@ -118,10 +118,6 @@ .con_initcall.init : { *(.con_initcall.init) } __con_initcall_end = .; SECURITY_INIT - . = ALIGN(4096); - __initramfs_start = .; - .init.ramfs : { *(.init.ramfs) } - __initramfs_end = .; . = ALIGN(32); __per_cpu_start = .; .data.percpu : { *(.data.percpu) } From eckhardt@satorlaser.com Wed Mar 16 05:53:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 05:54:05 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.184]:37836 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 05:53:49 +0000 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DBRTY-0007at-00; Wed, 16 Mar 2005 06:53:48 +0100 Received: from [213.39.155.219] (helo=c155219.adsl.hansenet.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DBRTX-0007cE-00; Wed, 16 Mar 2005 06:53:48 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA Date: Wed, 16 Mar 2005 06:51:42 +0100 User-Agent: KMail/1.7.1 References: <200503151245.15920.eckhardt@satorlaser.com> <42371C05.7060401@embeddedalley.com> In-Reply-To: <42371C05.7060401@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503160651.42705.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1283 Lines: 29 On Tuesday 15 March 2005 18:31, Pete Popov wrote: > > 2. How can I find out if it's looking at the right addresses? I just need > > some kind of register which I can probe to find out if the device is > > where I think it should be. > > > > Hmm, in fact I'd be happy about _any_ hint the would get me further. I'm > > slightly desparate... > > Start with the low level routines that detect the card and set the voltage > levels. When you plug in the card, is it detected? Are you setting the > correct voltages? What happens next -- is the card at least recognized by > the cardmgr, which means that the attribute memory is read correctly? I don't see any message that something is found, nor can I definitely say where an error happens. I mainly see two parts: one where cardservices are initialised and one where the driver registers itself. The former doesn't say it found anything at all, maybe that is already the problem... I'll investigate further. Could you post the relevant messages of a working system, so I could compare that? Hmmm, I just had a scary thought: I don't have any userspace programs running yet, meaning also no cardmgr, because I intend to boot from that CF card - is that possible at all? FYI, I don't need any hotplugging at all. thanks Uli From ppopov@embeddedalley.com Wed Mar 16 06:06:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 06:06:32 +0000 (GMT) Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:23705 "HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Wed, 16 Mar 2005 06:06:15 +0000 Received: from unknown (HELO ?192.168.1.100?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 16 Mar 2005 06:06:12 -0000 Message-ID: <4237CCDC.1030104@embeddedalley.com> Date: Tue, 15 Mar 2005 22:06:20 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA References: <200503151245.15920.eckhardt@satorlaser.com> <42371C05.7060401@embeddedalley.com> <200503160651.42705.eckhardt@satorlaser.com> In-Reply-To: <200503160651.42705.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 2459 Lines: 50 Ulrich Eckhardt wrote: > On Tuesday 15 March 2005 18:31, Pete Popov wrote: > >>>2. How can I find out if it's looking at the right addresses? I just need >>>some kind of register which I can probe to find out if the device is >>>where I think it should be. >>> >>>Hmm, in fact I'd be happy about _any_ hint the would get me further. I'm >>>slightly desparate... >> >>Start with the low level routines that detect the card and set the voltage >>levels. When you plug in the card, is it detected? Are you setting the >>correct voltages? What happens next -- is the card at least recognized by >>the cardmgr, which means that the attribute memory is read correctly? > > > I don't see any message that something is found, nor can I definitely say > where an error happens. I mainly see two parts: one where cardservices are > initialised and one where the driver registers itself. The former doesn't say > it found anything at all, maybe that is already the problem... I'll > investigate further. What I meant to say is to add debug prints to the driver so you can see if it detects and powers on the slot. > Could you post the relevant messages of a working system, so I could compare > that? I can do that ... just don't know if I'll get to it in the next couple of days. > Hmmm, I just had a scary thought: I don't have any userspace programs running > yet, meaning also no cardmgr, because I intend to boot from that CF card - is > that possible at all? FYI, I don't need any hotplugging at all. Do you really mean "boot" from it or "root" from it? If you want to "boot" from it, you need to work on your boot loader to be able to fetch the kernel from CF. If you mean "root" from it, then you are approaching this the wrong way -- it won't work through the pcmcia stack and cardmgr because that means you already have a root fs up and mounted. You could do this by creating a small ramdisk to serve as the root fs, run a special script on startup that loads the driver, starts cardmgr, cardmgr then detects the card and loads ide-cs.o, and finally the script exits back to the kernel. At that point the kernel mounts the real rootfs which is on the card itself. Or, you use the ide mode/feature of CF and get it to work that way, but I've never had to do that myself. Then the card looks like an ide device. That's something one of our guys at Embedded Alley has done in the past. Don't know how easy it is; I'll ping him. Pete From eckhardt@satorlaser.com Wed Mar 16 07:16:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 07:17:11 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.176]:6879 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 07:16:55 +0000 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DBSly-0001oS-00 for linux-mips@linux-mips.org; Wed, 16 Mar 2005 08:16:54 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DBSlx-00081P-00 for linux-mips@linux-mips.org; Wed, 16 Mar 2005 08:16:54 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA Date: Wed, 16 Mar 2005 08:16:52 +0100 User-Agent: KMail/1.7.1 References: <200503151245.15920.eckhardt@satorlaser.com> <200503160651.42705.eckhardt@satorlaser.com> <4237CCDC.1030104@embeddedalley.com> In-Reply-To: <4237CCDC.1030104@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503160816.52467.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1677 Lines: 37 Pete Popov wrote: > Ulrich Eckhardt wrote: > > Hmmm, I just had a scary thought: I don't have any userspace programs > > running yet, meaning also no cardmgr, because I intend to boot from that > > CF card - is that possible at all? FYI, I don't need any hotplugging at > > all. > > Do you really mean "boot" from it or "root" from it? If you want to "boot" > from it, you need to work on your boot loader to be able to fetch the > kernel from CF. I have two MiB of flash on board, which contains the bootloader (YAMON) and some free space for a kernel. This is used to boot from. IOW, I mean to root from the CF card, not to boot from it. > If you mean "root" from it, then you are approaching this > the wrong way -- it won't work through the pcmcia stack and cardmgr because > that means you already have a root fs up and mounted. You could do this by > creating a small ramdisk to serve as the root fs, run a special script on > startup that loads the driver, starts cardmgr, cardmgr then detects the > card and loads ide-cs.o, and finally the script exits back to the kernel. > At that point the kernel mounts the real rootfs which is on the card > itself. Sounds like the way to go. > Or, you use the ide mode/feature of CF and get it to work that way, but > I've never had to do that myself. Then the card looks like an ide device. > That's something one of our guys at Embedded Alley has done in the past. > Don't know how easy it is; I'll ping him. Sounds like another way to go, in particular since I don't need hotplugging and other PCMCIA features (and their overhead). Pete, I owe you a beer. I can see a few things much, much clearer now, thanks! Uli From ppopov@embeddedalley.com Wed Mar 16 08:02:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 08:02:33 +0000 (GMT) Received: from smtp008.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.74]:60854 "HELO smtp008.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Wed, 16 Mar 2005 08:02:17 +0000 Received: from unknown (HELO ?192.168.1.100?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp008.bizmail.sc5.yahoo.com with SMTP; 16 Mar 2005 08:02:14 -0000 Message-ID: <4237E80F.90305@embeddedalley.com> Date: Wed, 16 Mar 2005 00:02:23 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA References: <200503151245.15920.eckhardt@satorlaser.com> <200503160651.42705.eckhardt@satorlaser.com> <4237CCDC.1030104@embeddedalley.com> <200503160816.52467.eckhardt@satorlaser.com> In-Reply-To: <200503160816.52467.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 680 Lines: 18 >>Or, you use the ide mode/feature of CF and get it to work that way, but >>I've never had to do that myself. Then the card looks like an ide device. >>That's something one of our guys at Embedded Alley has done in the past. >>Don't know how easy it is; I'll ping him. > > > Sounds like another way to go, in particular since I don't need hotplugging > and other PCMCIA features (and their overhead). Right. And it shouldn't be that hard, but the support just isn't there so some work is involved. Finding an example would be the way to go. > Pete, I owe you a beer. I can see a few things much, much clearer now, thanks! So open source is indeed about free beer :) Pete From ralf@linux-mips.org Wed Mar 16 10:28:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 10:28:31 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:536 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 10:28:16 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2FLtdas027210; Tue, 15 Mar 2005 21:55:39 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2FLtd9i027209; Tue, 15 Mar 2005 21:55:39 GMT Date: Tue, 15 Mar 2005 21:55:39 +0000 From: Ralf Baechle To: Jim Gifford Cc: Linux MIPS List Subject: Re: Current Build Warning Message Message-ID: <20050315215538.GJ6025@linux-mips.org> References: <42375617.3020002@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42375617.3020002@jg555.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 765 Lines: 22 On Tue, Mar 15, 2005 at 01:39:35PM -0800, Jim Gifford wrote: > Date: Tue, 15 Mar 2005 13:39:35 -0800 > From: Jim Gifford > To: Linux MIPS List > Subject: Current Build Warning Message > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I just tried doing a current build on a 2.6.11 systems. I get the > following warnings. > > *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! > *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined! > > Any ideas on how to correct this? Write pci_iounmap and pci_iomap :-) (Recently an implementation was posted here but it's been broken as it only did support a single PCI bus and will fail silently for additional busses.) Ralf From ralf@linux-mips.org Wed Mar 16 12:07:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 12:08:17 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:25099 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 12:07:52 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2GC6oZN011092; Wed, 16 Mar 2005 12:06:50 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2GC6mKL011091; Wed, 16 Mar 2005 12:06:48 GMT Date: Wed, 16 Mar 2005 12:06:47 +0000 From: Ralf Baechle To: Ed Martini Cc: linux-mips@linux-mips.org Subject: Re: initrd problem Message-ID: <20050316120647.GB8563@linux-mips.org> References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423763B9.2000907@c2micro.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1767 Lines: 41 On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote: > Ok. Then let's get rid of it completly, and provide a replacement that > works. Way to go. > There were vestiges of embedded initrd in the ld script that were > confusing when trying to sort things out. That, in conjunction with > Documentation/initrd.txt made it hard to discover early user space and > initramfs when coming from the old world (2.4). Correct and I've applied that part of your patch already while thinking about the problem you describe below. > Also, unless you move the location of .init.ramfs, it gets freed twice, > leading to a panic. Interesting one. When I tested the code recently it did work for me and it shouldn't have changed since. The way this is supposed to work is by setting the page_count to 1 by using set_page_count and unmarking the page as reserved, so after that point a free_page should actually succeed - even if done twice as you've observed, first in populate_rootfs then once more in free_initmem. It seems a frighteningly bad idea though since it relies on no memory from the initrd range being allocated between the two calls - or it would end being freed by force, in use or not. On startup Linux tends to allocate memory starting from high address towards low addresses which must be why we usually get away with this one. > From the documentation alone it's impossible to figure out how to build > your initramfs. In various places the docs refer to the initial > executable as /linuxrc, /kinit, /init, and possibly others. If you read > init/main.c you see that for an initramfs, your initial process will be > started from /init. I guess I read the code so I didn't notice the lacking qualities of the documentation ... Ralf From drow@nevyn.them.org Wed Mar 16 14:12:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 14:12:26 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:51370 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 14:12:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1DBZFY-00067n-AV; Wed, 16 Mar 2005 09:11:52 -0500 Date: Wed, 16 Mar 2005 09:11:52 -0500 From: Daniel Jacobowitz To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: NPTL support for the kernel Message-ID: <20050316141151.GA23225@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 14198 Lines: 440 Here's a kernel patch to enable NPTL support. This doesn't include Maciej's uber-fast rdhwr emulation; I believe we ought to include both the fast and slow paths, since the slow path will handle use of other destination registers. Changes: - Clone takes five arguments, not four. Um, this bit is gross. - New syscall sys_set_thread_area. Only glibc uses this. - Emulation of the rdhwr instruction. This version is only loosely based on the emulation on the malta branch; the major difference is that I fixed ll/sc/rdhwr emulation in branch delay slots. GCC 4.1 will generate rdhwr in branch delay slots in some conditions. - PTRACE_GET_THREAD_AREA support for GDB. How's it look? I've just finished hopefully final tests for the glibc bits, and will post them once this patch is resolved. [Credit goes to Manish Lachwani at MontaVista for writing the first draft of this patch, though he won't recognize most of this copy :-)] Index: linux/arch/mips/kernel/syscall.c =================================================================== --- linux.orig/arch/mips/kernel/syscall.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/syscall.c 2005-03-15 10:30:09.000000000 -0500 @@ -176,14 +176,28 @@ _sys_clone(nabi_no_regargs struct pt_reg { unsigned long clone_flags; unsigned long newsp; - int *parent_tidptr, *child_tidptr; + int __user *parent_tidptr, *child_tidptr; clone_flags = regs.regs[4]; newsp = regs.regs[5]; if (!newsp) newsp = regs.regs[29]; - parent_tidptr = (int *) regs.regs[6]; - child_tidptr = (int *) regs.regs[7]; + parent_tidptr = (int __user *) regs.regs[6]; +#ifdef CONFIG_MIPS32 + /* We need to fetch the fifth argument off the stack. */ + child_tidptr = NULL; + if (clone_flags & (CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID)) { + int __user *__user *usp = (int __user *__user *) regs.regs[29]; + if (regs.regs[2] == __NR_syscall) { + if (get_user (child_tidptr, &usp[5])) + return -EFAULT; + } + else if (get_user (child_tidptr, &usp[4])) + return -EFAULT; + } +#else + child_tidptr = (int __user *) regs.regs[8]; +#endif return do_fork(clone_flags, newsp, ®s, 0, parent_tidptr, child_tidptr); } @@ -245,6 +259,16 @@ asmlinkage int sys_olduname(struct oldol return error; } +void sys_set_thread_area(unsigned long addr) +{ + struct thread_info *ti = current->thread_info; + + ti->tp_value = addr; + + /* If some future MIPS implementation has this register in hardware, + * we will need to update it here (and in context switches). */ +} + asmlinkage int _sys_sysmips(int cmd, long arg1, int arg2, int arg3) { int tmp, len; Index: linux/arch/mips/kernel/traps.c =================================================================== --- linux.orig/arch/mips/kernel/traps.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/traps.c 2005-03-15 10:33:48.000000000 -0500 @@ -360,6 +360,10 @@ static inline int get_insn_opcode(struct #define OFFSET 0x0000ffff #define LL 0xc0000000 #define SC 0xe0000000 +#define SPEC3 0x7c000000 +#define RD 0x0000f800 +#define FUNC 0x0000003f +#define RDHWR 0x0000003b /* * The ll_bit is cleared by r*_switch.S @@ -408,9 +412,10 @@ static inline void simulate_ll(struct pt preempt_enable(); + compute_return_epc(regs); + regs->regs[(opcode & RT) >> 16] = value; - compute_return_epc(regs); return; sig: @@ -446,9 +451,9 @@ static inline void simulate_sc(struct pt preempt_disable(); if (ll_bit == 0 || ll_task != current) { - regs->regs[reg] = 0; preempt_enable(); compute_return_epc(regs); + regs->regs[reg] = 0; return; } @@ -459,9 +464,8 @@ static inline void simulate_sc(struct pt goto sig; } - regs->regs[reg] = 1; - compute_return_epc(regs); + regs->regs[reg] = 1; return; sig: @@ -494,6 +498,37 @@ static inline int simulate_llsc(struct p return -EFAULT; /* Strange things going on ... */ } +/* + * Simulate trapping 'rdhwr' instructions to provide user accessible + * registers not implemented in hardware. The only current use of this + * is the thread area pointer. + */ +static inline int simulate_rdhwr(struct pt_regs *regs) +{ + struct thread_info *ti = current->thread_info; + unsigned int opcode; + + if (unlikely(get_insn_opcode(regs, &opcode))) + return -EFAULT; + + if (unlikely(compute_return_epc(regs))) + return -EFAULT; + + if ((opcode & OPCODE) == SPEC3 && (opcode & FUNC) == RDHWR) { + int rd = (opcode & RD) >> 11; + int rt = (opcode & RT) >> 16; + switch (rd) { + case 29: + regs->regs[rt] = ti->tp_value; + break; + default: + return -EFAULT; + } + } + + return 0; +} + asmlinkage void do_ov(struct pt_regs *regs) { siginfo_t info; @@ -640,6 +675,9 @@ asmlinkage void do_ri(struct pt_regs *re if (!simulate_llsc(regs)) return; + if (!simulate_rdhwr(regs)) + return; + force_sig(SIGILL, current); } @@ -653,11 +691,13 @@ asmlinkage void do_cpu(struct pt_regs *r switch (cpid) { case 0: - if (cpu_has_llsc) - break; + if (!cpu_has_llsc) + if (!simulate_llsc(regs)) + return; - if (!simulate_llsc(regs)) + if (!simulate_rdhwr(regs)) return; + break; case 1: Index: linux/arch/mips/kernel/process.c =================================================================== --- linux.orig/arch/mips/kernel/process.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/process.c 2005-03-16 09:04:04.049856461 -0500 @@ -89,6 +89,7 @@ int copy_thread(int nr, unsigned long cl struct thread_info *ti = p->thread_info; struct pt_regs *childregs; long childksp; + p->set_child_tid = p->clear_child_tid = NULL; childksp = (unsigned long)ti + THREAD_SIZE - 32; @@ -134,6 +135,9 @@ int copy_thread(int nr, unsigned long cl childregs->cp0_status &= ~(ST0_CU2|ST0_CU1); clear_tsk_thread_flag(p, TIF_USEDFPU); + if (clone_flags & CLONE_SETTLS) + ti->tp_value = regs->regs[7]; + return 0; } Index: linux/include/asm-mips/inst.h =================================================================== --- linux.orig/include/asm-mips/inst.h 2005-03-15 10:09:23.000000000 -0500 +++ linux/include/asm-mips/inst.h 2005-03-15 10:09:29.000000000 -0500 @@ -28,7 +28,7 @@ enum major_op { sdl_op, sdr_op, swr_op, cache_op, ll_op, lwc1_op, lwc2_op, pref_op, lld_op, ldc1_op, ldc2_op, ld_op, - sc_op, swc1_op, swc2_op, major_3b_op, /* Opcode 0x3b is unused */ + sc_op, swc1_op, swc2_op, rdhwr_op, scd_op, sdc1_op, sdc2_op, sd_op }; Index: linux/arch/mips/kernel/ptrace.c =================================================================== --- linux.orig/arch/mips/kernel/ptrace.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/ptrace.c 2005-03-15 10:09:29.000000000 -0500 @@ -287,6 +287,11 @@ asmlinkage int sys_ptrace(long request, ret = ptrace_detach(child, data); break; + case PTRACE_GET_THREAD_AREA: + ret = put_user(child->thread_info->tp_value, + (unsigned long __user *) data); + break; + default: ret = ptrace_request(child, request, addr, data); break; Index: linux/include/asm-mips/thread_info.h =================================================================== --- linux.orig/include/asm-mips/thread_info.h 2005-03-15 10:09:23.000000000 -0500 +++ linux/include/asm-mips/thread_info.h 2005-03-15 10:34:51.000000000 -0500 @@ -26,6 +26,7 @@ struct thread_info { struct task_struct *task; /* main task structure */ struct exec_domain *exec_domain; /* execution domain */ unsigned long flags; /* low level flags */ + unsigned long tp_value; /* thread pointer */ __u32 cpu; /* current CPU */ __s32 preempt_count; /* 0 => preemptable, <0 => BUG */ Index: linux/arch/mips/kernel/offset.c =================================================================== --- linux.orig/arch/mips/kernel/offset.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/offset.c 2005-03-15 10:09:29.000000000 -0500 @@ -95,6 +95,7 @@ void output_thread_info_defines(void) offset("#define TI_PRE_COUNT ", struct thread_info, preempt_count); offset("#define TI_ADDR_LIMIT ", struct thread_info, addr_limit); offset("#define TI_RESTART_BLOCK ", struct thread_info, restart_block); + offset("#define TI_TP_VALUE ", struct thread_info, tp_value); constant("#define _THREAD_SIZE_ORDER ", THREAD_SIZE_ORDER); constant("#define _THREAD_SIZE ", THREAD_SIZE); constant("#define _THREAD_MASK ", THREAD_MASK); Index: linux/arch/mips/kernel/scall64-o32.S =================================================================== --- linux.orig/arch/mips/kernel/scall64-o32.S 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/scall64-o32.S 2005-03-15 10:29:46.000000000 -0500 @@ -322,7 +322,7 @@ sys_call_table: PTR sys32_ipc PTR sys_fsync PTR sys32_sigreturn - PTR sys_clone /* 4120 */ + PTR sys32_clone /* 4120 */ PTR sys_setdomainname PTR sys32_newuname PTR sys_ni_syscall /* sys_modify_ldt */ @@ -485,4 +485,5 @@ sys_call_table: PTR sys_add_key /* 4280 */ PTR sys_request_key PTR sys_keyctl + PTR sys_set_thread_area .size sys_call_table,.-sys_call_table Index: linux/arch/mips/kernel/linux32.c =================================================================== --- linux.orig/arch/mips/kernel/linux32.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/linux32.c 2005-03-15 10:29:02.000000000 -0500 @@ -1471,3 +1471,38 @@ sysn32_rt_sigtimedwait(const sigset_t __ } return sys_rt_sigtimedwait(uthese, uinfo, uts, sigsetsize); } + +save_static_function(sys32_clone); +__attribute_used__ noinline static int +_sys32_clone(unsigned long __dummy0, + unsigned long __dummy1, + unsigned long __dummy2, + unsigned long __dummy3, + unsigned long __dummy4, + unsigned long __dummy5, + unsigned long __dummy6, + unsigned long __dummy7, + struct pt_regs regs) +{ + unsigned long clone_flags; + unsigned long newsp; + int __user *parent_tidptr, *child_tidptr; + + clone_flags = regs.regs[4]; + newsp = regs.regs[5]; + if (!newsp) + newsp = regs.regs[29]; + parent_tidptr = (int *) regs.regs[6]; + + /* Use __dummy4 instead of getting it off the stack, so that + syscall() works. */ + child_tidptr = (int __user *) __dummy4; + return do_fork(clone_flags, newsp, ®s, 0, + parent_tidptr, child_tidptr); +} + +extern asmlinkage void sys_set_thread_area(u32 addr); +asmlinkage void sys32_set_thread_area(u32 addr) +{ + sys_set_thread_area(AA(addr)); +} Index: linux/arch/mips/kernel/ptrace32.c =================================================================== --- linux.orig/arch/mips/kernel/ptrace32.c 2005-03-15 10:09:23.000000000 -0500 +++ linux/arch/mips/kernel/ptrace32.c 2005-03-15 10:09:29.000000000 -0500 @@ -268,6 +268,11 @@ asmlinkage int sys32_ptrace(int request, wake_up_process(child); break; + case PTRACE_GET_THREAD_AREA: + ret = put_user(child->thread_info->tp_value, + (unsigned int __user *) (unsigned long) data); + break; + case PTRACE_DETACH: /* detach a process that was attached. */ ret = ptrace_detach(child, data); break; Index: linux/arch/mips/kernel/scall32-o32.S =================================================================== --- linux.orig/arch/mips/kernel/scall32-o32.S 2005-03-15 10:04:30.000000000 -0500 +++ linux/arch/mips/kernel/scall32-o32.S 2005-03-15 10:29:24.000000000 -0500 @@ -623,6 +623,7 @@ einval: li v0, -EINVAL sys sys_add_key 5 sys sys_request_key 4 sys sys_keyctl 5 + sys sys_set_thread_area 1 .endm Index: linux/include/asm-mips/unistd.h =================================================================== --- linux.orig/include/asm-mips/unistd.h 2005-02-02 09:17:33.000000000 -0500 +++ linux/include/asm-mips/unistd.h 2005-03-15 10:26:02.000000000 -0500 @@ -303,16 +303,17 @@ #define __NR_add_key (__NR_Linux + 280) #define __NR_request_key (__NR_Linux + 281) #define __NR_keyctl (__NR_Linux + 282) +#define __NR_set_thread_area (__NR_Linux + 283) /* * Offset of the last Linux o32 flavoured syscall */ -#define __NR_Linux_syscalls 282 +#define __NR_Linux_syscalls 283 #endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */ #define __NR_O32_Linux 4000 -#define __NR_O32_Linux_syscalls 282 +#define __NR_O32_Linux_syscalls 283 #if _MIPS_SIM == _MIPS_SIM_ABI64 @@ -562,16 +563,17 @@ #define __NR_add_key (__NR_Linux + 239) #define __NR_request_key (__NR_Linux + 240) #define __NR_keyctl (__NR_Linux + 241) +#define __NR_set_thread_area (__NR_Linux + 242) /* * Offset of the last Linux 64-bit flavoured syscall */ -#define __NR_Linux_syscalls 241 +#define __NR_Linux_syscalls 242 #endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */ #define __NR_64_Linux 5000 -#define __NR_64_Linux_syscalls 241 +#define __NR_64_Linux_syscalls 242 #if _MIPS_SIM == _MIPS_SIM_NABI32 @@ -825,16 +827,17 @@ #define __NR_add_key (__NR_Linux + 243) #define __NR_request_key (__NR_Linux + 244) #define __NR_keyctl (__NR_Linux + 245) +#define __NR_set_thread_area (__NR_Linux + 246) /* * Offset of the last N32 flavoured syscall */ -#define __NR_Linux_syscalls 245 +#define __NR_Linux_syscalls 246 #endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */ #define __NR_N32_Linux 6000 -#define __NR_N32_Linux_syscalls 245 +#define __NR_N32_Linux_syscalls 246 #ifndef __ASSEMBLY__ Index: linux/arch/mips/kernel/scall64-64.S =================================================================== --- linux.orig/arch/mips/kernel/scall64-64.S 2005-01-20 16:26:58.000000000 -0500 +++ linux/arch/mips/kernel/scall64-64.S 2005-03-15 10:29:48.000000000 -0500 @@ -449,3 +449,4 @@ sys_call_table: PTR sys_add_key PTR sys_request_key /* 5240 */ PTR sys_keyctl + PTR sys_set_thread_area Index: linux/arch/mips/kernel/scall64-n32.S =================================================================== --- linux.orig/arch/mips/kernel/scall64-n32.S 2005-03-15 10:09:21.000000000 -0500 +++ linux/arch/mips/kernel/scall64-n32.S 2005-03-16 09:04:03.388011517 -0500 @@ -363,3 +363,4 @@ EXPORT(sysn32_call_table) PTR sys_add_key PTR sys_request_key PTR sys_keyctl /* 6245 */ + PTR sys_set_thread_area -- Daniel Jacobowitz CodeSourcery, LLC From eckhardt@satorlaser.com Wed Mar 16 17:08:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 17:08:30 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.187]:20194 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 17:08:13 +0000 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1DBc0C1zqu-0001uz; Wed, 16 Mar 2005 18:08:12 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA Date: Wed, 16 Mar 2005 18:08:09 +0100 User-Agent: KMail/1.7.1 References: <200503151245.15920.eckhardt@satorlaser.com> <200503160816.52467.eckhardt@satorlaser.com> <4237E80F.90305@embeddedalley.com> In-Reply-To: <4237E80F.90305@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503161808.10088.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1420 Lines: 30 Pete Popov wrote: > >>Or, you use the ide mode/feature of CF and get it to work that way, but > >>I've never had to do that myself. Then the card looks like an ide device. > >>That's something one of our guys at Embedded Alley has done in the past. > >>Don't know how easy it is; I'll ping him. > > > > Sounds like another way to go, in particular since I don't need > > hotplugging and other PCMCIA features (and their overhead). > > Right. And it shouldn't be that hard, but the support just isn't there so > some work is involved. Finding an example would be the way to go. OK, I'm just giving a short update on what I've found. In asm-mips/mach-generic/ide.h is a function ide_probe_legacy() which is called to determine IDE support but which returns 0 for my setup. I simply hard-wired this value to 1 and now at least it tries to probe something. However, it is looking at ioports in the range 366-3f6, which are already reserved by something else. Anyway, that is rather a legacy PC-style layout and thus probably doesn't apply to the PCMCIA version, if I'm not mistaken. I also tried simply removing the check whether they are reserved, but that just OOPSed. Looking at EBOOT (a bootloader for win CE that boots off the compactflash), it tries to access the IDE interface at address 0x1a00000 for io_addr and 0x1a00000e for control, let's see if I can find any IDE hardware at that address... Uli From ppopov@embeddedalley.com Wed Mar 16 17:21:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 17:21:23 +0000 (GMT) Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:5222 "HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 16 Mar 2005 17:21:08 +0000 Received: from unknown (HELO ?192.168.1.100?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp001.bizmail.yahoo.com with SMTP; 16 Mar 2005 17:21:05 -0000 Message-ID: <42386B0A.5070006@embeddedalley.com> Date: Wed, 16 Mar 2005 09:21:14 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA References: <200503151245.15920.eckhardt@satorlaser.com> <200503160816.52467.eckhardt@satorlaser.com> <4237E80F.90305@embeddedalley.com> <200503161808.10088.eckhardt@satorlaser.com> In-Reply-To: <200503161808.10088.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1223 Lines: 24 > OK, I'm just giving a short update on what I've found. In > asm-mips/mach-generic/ide.h is a function ide_probe_legacy() which is called > to determine IDE support but which returns 0 for my setup. I simply > hard-wired this value to 1 and now at least it tries to probe something. > > However, it is looking at ioports in the range 366-3f6, which are already > reserved by something else. Anyway, that is rather a legacy PC-style layout > and thus probably doesn't apply to the PCMCIA version, if I'm not mistaken. I > also tried simply removing the check whether they are reserved, but that just > OOPSed. > > Looking at EBOOT (a bootloader for win CE that boots off the compactflash), it > tries to access the IDE interface at address 0x1a00000 for io_addr and > 0x1a00000e for control, let's see if I can find any IDE hardware at that > address... Uhm, I don't think you'll resolve this that easily. There is some code that needs to go in the au1x00 socket driver which means you would have to understand pretty well how this thing works. Ultimately the addresses you'll probe are very high ioremapped addresses, since the pcmcia attribute, common mem, and i/o are 36 bit physical addresses. Pete From macro@linux-mips.org Wed Mar 16 18:51:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 18:51:36 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:16141 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 18:51:20 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7D69EF5946; Wed, 16 Mar 2005 19:51:11 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18945-03; Wed, 16 Mar 2005 19:51:11 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 389B0E1CBD; Wed, 16 Mar 2005 19:51:11 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j2GIpGY2016620; Wed, 16 Mar 2005 19:51:16 +0100 Date: Wed, 16 Mar 2005 18:51:26 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux In-Reply-To: <20050304151343Z8225933-1340+3959@linux-mips.org> Message-ID: References: <20050304151343Z8225933-1340+3959@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/700/Fri Feb 4 00:33:15 2005 clamav-milter version 0.80j on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 315 Lines: 10 On Fri, 4 Mar 2005 ralf@linux-mips.org wrote: > Log message: > On Qube2700 Galileo hangs if we access slot #6. Device #31 is reserved with Galileo controllers for generating special cycles. Thus it's a feature rather than an erratum and I think it's worth being properly documented in the sources. Maciej From ellis@spinics.net Wed Mar 16 22:47:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 22:47:51 +0000 (GMT) Received: from spinics.net ([IPv6:::ffff:66.254.95.226]:64224 "EHLO spinics.net") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 22:47:36 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by spinics.net (8.12.8/8.12.8) with ESMTP id j2GMlXRF017149 for ; Wed, 16 Mar 2005 14:47:33 -0800 Received: (from ellis@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j2GMlXPh017146 for linux-mips@linux-mips.org; Wed, 16 Mar 2005 14:47:33 -0800 From: ellis@spinics.net Message-Id: <200503162247.j2GMlXPh017146@localhost.localdomain> Subject: Little Endian To: linux-mips@linux-mips.org Date: Wed, 16 Mar 2005 14:47:33 -0800 (PST) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ellis@spinics.net Precedence: bulk X-list: linux-mips Content-Length: 284 Lines: 8 I'm just starting to look at a porting project. The board I'll be using is little endian and the CVS version of the kernel source doesn't have anything but big endian in the config menu. Does little endian work at all and if so, how do I select it? -- http://www.spinics.net/linux/ From mlachwani@mvista.com Wed Mar 16 23:10:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Mar 2005 23:10:44 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44275 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Wed, 16 Mar 2005 23:10:29 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 5CB4018B9A; Wed, 16 Mar 2005 15:10:27 -0800 (PST) Message-ID: <4238BCE3.2030003@mvista.com> Date: Wed, 16 Mar 2005 15:10:27 -0800 From: Manish Lachwani User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ellis@spinics.net Cc: linux-mips@linux-mips.org Subject: Re: Little Endian References: <200503162247.j2GMlXPh017146@localhost.localdomain> In-Reply-To: <200503162247.j2GMlXPh017146@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mlachwani@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1409 Lines: 37 ellis@spinics.net wrote: >I'm just starting to look at a porting project. The board I'll >be using is little endian and the CVS version of the kernel >source doesn't have anything but big endian in the config >menu. Does little endian work at all and if so, how do I >select it? > >-- >http://www.spinics.net/linux/ > > > When you do "make menuconfig", under "Machine Selection" item, there is an option called "Generate little endian code". Is this what you are looking for? This is a config option CONFIG_CPU_LITTLE_ENDIAN. This is defined in arch/mips/Kconfig: config CPU_LITTLE_ENDIAN bool "Generate little endian code" default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477 || MACH_DECSTATION || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR || SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI || VICTOR_MPC30X || ZAO_CAPCELLA default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT || MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927 help Some MIPS machines can be configured for either little or big endian byte order. These modes require different kernels. Say Y if your machine is little endian, N if it's a big endian machine. Thanks Manish Lachwani From martini@c2micro.com Thu Mar 17 00:25:40 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 00:25:55 +0000 (GMT) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:8950 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 00:25:40 +0000 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id 9CDDD25C95F; Wed, 16 Mar 2005 16:25:34 -0800 (PST) Message-ID: <4238CE11.8000506@c2micro.com> Date: Wed, 16 Mar 2005 16:23:45 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle Cc: linux-mips@linux-mips.org, lkml@vger.kernel.org Subject: initrd/initramfs problem References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> <20050316120647.GB8563@linux-mips.org> In-Reply-To: <20050316120647.GB8563@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7453 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 2234 Lines: 68 What fails is when CONFIG_BLK_DEV_INITRD and CONFIG_INITRAMFS_SOURCE are both set. I realize (now) that I don't need initrd at all, and initramfs works fine by itself, as you have tested. It seems that the kernel may need some exclusion between these two mechanisms while the difference is sorted out. I'm not totally up on Kconfig files, but maybe something like this in drivers/block/Kconfig: config INITRAMFS_SOURCE string "Initramfs source file(s)" default "" depends on BLK_DEV_INITRD=n Regarding the documenation it would have been helpful to me if Documentation/initrd.txt had a reference to Documentation/early-userspace/README. I'm not sure who maintains that directory, or I'd send a suggestion. tldp.org? THX Ed Martini Original context: http://www.linux-mips.org/archives/linux-mips/2005-03/index.html Ralf Baechle wrote: >On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote: > > > >>Also, unless you move the location of .init.ramfs, it gets freed twice, >>leading to a panic. >> >> > >Interesting one. When I tested the code recently it did work for me and >it shouldn't have changed since. The way this is supposed to work is >by setting the page_count to 1 by using set_page_count and unmarking the >page as reserved, so after that point a free_page should actually succeed - >even if done twice as you've observed, first in populate_rootfs then >once more in free_initmem. > >It seems a frighteningly bad idea though since it relies on no memory >from the initrd range being allocated between the two calls - or it would >end being freed by force, in use or not. On startup Linux tends to >allocate memory starting from high address towards low addresses which >must be why we usually get away with this one. > > > >>From the documentation alone it's impossible to figure out how to build >>your initramfs. In various places the docs refer to the initial >>executable as /linuxrc, /kinit, /init, and possibly others. If you read >>init/main.c you see that for an initramfs, your initial process will be >>started from /init. >> >> > >I guess I read the code so I didn't notice the lacking qualities of the >documentation ... > > Ralf > > From leonel.gayard@gmail.com Thu Mar 17 02:54:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 02:54:30 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.206]:52359 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 02:54:16 +0000 Received: by wproxy.gmail.com with SMTP id 55so90889wri for ; Wed, 16 Mar 2005 18:54:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=lrojtX8i0uqXNkYOAgB7Z2YeOazSHAR21q/qaROH1MT1FsMuBkqBSYx7w/5Y/ZrQ5hw3KBDJUCZ89KJouv4Rz59hpkmj+10s2tN40gT9ux0I/S0ebrbKPH+IzJTRk0OzdE31Xcf6dVHTm6KJQZSdDjqX71AgfZPvvBlecqWcg+E= Received: by 10.54.14.31 with SMTP id 31mr1443316wrn; Wed, 16 Mar 2005 18:54:09 -0800 (PST) Received: by 10.54.28.68 with HTTP; Wed, 16 Mar 2005 18:54:09 -0800 (PST) Message-ID: <2ccb2254050316185449699409@mail.gmail.com> Date: Thu, 17 Mar 2005 02:54:09 +0000 From: Leonel Gayard Reply-To: Leonel Gayard To: linux-mips@linux-mips.org Subject: How do I compile GCC to generate MIPS code ? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: leonel.gayard@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 699 Lines: 25 Hi all, I have recently started to study the MIPS architecture. For instance, I wanted to have GCC compile C code into MIPS assembly and run it in SPIM. (I have an Intel machine running Linux). So I want to try something like this: gcc -Wall -pedantic -S --march=mips1 test.c in order to have it generate MIPS assembly. It does not work. All I get is: cc1: error: bad value (mips32) for -march= switch cc1: error: bad value (mips32) for -mcpu= switch Clearly, I need to recompile GCC so it has MIPS in its available architectures. Remark, this is not cross-compiling, because I want GCC to run on an i686 machine, it just generates MIPS code. Can any one help me do this ? Thank you Leonel From sjhill@realitydiluted.com Thu Mar 17 04:21:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 04:21:54 +0000 (GMT) Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:18873 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 04:21:30 +0000 Received: from localhost ([127.0.0.1]) by real.realitydiluted.com with esmtp (Exim 4.50 #1 (Debian)) id 1DBmVl-0005CM-7u; Wed, 16 Mar 2005 22:21:29 -0600 Message-ID: <4239078B.7050000@realitydiluted.com> Date: Wed, 16 Mar 2005 22:28:59 -0600 From: "Steven J. Hill" User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leonel Gayard CC: linux-mips@linux-mips.org Subject: Re: How do I compile GCC to generate MIPS code ? References: <2ccb2254050316185449699409@mail.gmail.com> In-Reply-To: <2ccb2254050316185449699409@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Content-Length: 788 Lines: 25 Leonel Gayard wrote: > > I have recently started to study the MIPS architecture. For instance, > I wanted to have GCC compile C code into MIPS assembly and run it in > SPIM. (I have an Intel machine running Linux). > There are these brand new services just out called Google and Wiki!!! You should try them out. They're revolutionary!! All kidding aside, go to: http://www.linux-mips.org/ which is the main site. The link directly to the toolchains is: http://www.linux-mips.org/wiki/index.php/Toolchains more information about emulators/simulators is: http://www.linux-mips.org/wiki/index.php/Emulators All of the information that you are looking for will be there. Have lots of fun. Please feel free to ask questions after you have exhausted those resources. -Steve From kumba@gentoo.org Thu Mar 17 04:24:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 04:24:27 +0000 (GMT) Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:54154 "EHLO rwcrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 04:24:12 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (rwcrmhc11) with ESMTP id <2005031704240401300ed4fqe>; Thu, 17 Mar 2005 04:24:05 +0000 Message-ID: <4239066E.8080900@gentoo.org> Date: Wed, 16 Mar 2005 23:24:14 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leonel Gayard CC: linux-mips@linux-mips.org Subject: Re: How do I compile GCC to generate MIPS code ? References: <2ccb2254050316185449699409@mail.gmail.com> In-Reply-To: <2ccb2254050316185449699409@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1315 Lines: 40 Leonel Gayard wrote: > Hi all, > > I have recently started to study the MIPS architecture. For instance, > I wanted to have GCC compile C code into MIPS assembly and run it in > SPIM. (I have an Intel machine running Linux). > > So I want to try something like this: > > gcc -Wall -pedantic -S --march=mips1 test.c > > in order to have it generate MIPS assembly. > > It does not work. All I get is: > > cc1: error: bad value (mips32) for -march= switch > cc1: error: bad value (mips32) for -mcpu= switch > > Clearly, I need to recompile GCC so it has MIPS in its available > architectures. Remark, this is not cross-compiling, because I want GCC > to run on an i686 machine, it just generates MIPS code. > > Can any one help me do this ? > > Thank you > Leonel Cross compiling is the (black) art of building a compiler that runs on Arch X, but generates code for Arch Y. You definitely do not want to replace your system compiler (that is, i686-pc-linux-gnu-gcc) with a mips one, cause then you won't be able to rebuild i686 packages. You want a second compiler to be available capable of handling mips-unknown-linux-gnu. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From eckhardt@satorlaser.com Thu Mar 17 15:26:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 15:26:23 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.190]:5101 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 15:26:02 +0000 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DBwsq-0004xo-00 for linux-mips@linux-mips.org; Thu, 17 Mar 2005 16:26:00 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DBwsq-00069l-00 for linux-mips@linux-mips.org; Thu, 17 Mar 2005 16:26:00 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA Date: Thu, 17 Mar 2005 16:26:00 +0100 User-Agent: KMail/1.7.1 References: <200503151245.15920.eckhardt@satorlaser.com> <200503161808.10088.eckhardt@satorlaser.com> <42386B0A.5070006@embeddedalley.com> In-Reply-To: <42386B0A.5070006@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503171626.01092.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1878 Lines: 40 Pete Popov wrote: >> Looking at EBOOT (a bootloader for win CE that boots off the >> compactflash), it tries to access the IDE interface at address 0x1a00000 >> for io_addr and 0x1a00000e for control, let's see if I can find any IDE >> hardware at that address... > > Uhm, I don't think you'll resolve this that easily. There is some code that > needs to go in the au1x00 socket driver which means you would have to > understand pretty well how this thing works. Ultimately the addresses > you'll probe are very high ioremapped addresses, since the pcmcia > attribute, common mem, and i/o are 36 bit physical addresses. Looking at EBOOT, it creates these mappings here in the TLB: 0xf 0000 0000 -> 0x1a00 0000 (IO) 0xf 4000 0000 -> 0x1c00 0000 (attrib) 0xf 8000 0000 -> 0x1e00 0000 (mem) each time mapping 32MiB. In the Linux PCMCIA code, I see that only the IO range above gets ioremap()ed, and only 4KiB thereof. For the other two ranges, it uses two addresses that are intended for use with fixup_bigphys_addr()[1] but seem to target the equivalent physical addresses as in EBOOT. I tried simply ioremap()ing the IO region and looked for an ATA interface at the beginning of that range, but the contents of that memory seem to be rather random. I'll next try to remove both PCMCIA and IDE drivers, just to make sure they don't interact in any unforseeable way with my ad-hoc code, but that's scheduled for tuesday. I also found www.ata-atapi.com/atadrvr.zip, which contains low-level driver sourcecode and examples, so I have something to read over the weekend. ;) Thank you all for your help! Uli [1] Why the difference in the handling of the three ranges? Also, what additional effect does ioremap() have when compared to using the TLB? Is it that ioremap() is the Right Way(tm) on any architecture while TLB is the way that works only on MIPS? From yuasa@hh.iij4u.or.jp Thu Mar 17 15:47:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 15:48:12 +0000 (GMT) Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:205 "EHLO mo01.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 15:47:55 +0000 Received: MO(mo01)id j2HFlqjj027215; Fri, 18 Mar 2005 00:47:52 +0900 (JST) Received: MDO(mdo01) id j2HFlpVu002681; Fri, 18 Mar 2005 00:47:52 +0900 (JST) Received: 4UMRO00 id j2HFloJJ012817; Fri, 18 Mar 2005 00:47:51 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Fri, 18 Mar 2005 00:47:50 +0900 From: Yoichi Yuasa To: ralf@linux-mips.org Cc: yuasa@hh.iij4u.or.jp, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux Message-Id: <20050318004750.01b33b9e.yuasa@hh.iij4u.or.jp> In-Reply-To: <20050308014420.6253f8ce.yuasa@hh.iij4u.or.jp> References: <20050115013112Z8225557-1340+1316@linux-mips.org> <20050119134211.2c0e24f5.yuasa@hh.iij4u.or.jp> <20050119143146.09982d63.yuasa@hh.iij4u.or.jp> <20050119152151.7b756560.yuasa@hh.iij4u.or.jp> <20050308014420.6253f8ce.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Content-Length: 4394 Lines: 170 Hello again, On Tue, 8 Mar 2005 01:44:20 +0900 Yoichi Yuasa wrote: > Hello Ralf and Maciej, > > On Wed, 19 Jan 2005 15:21:51 +0900 > Yoichi Yuasa wrote: > > > Hi Maciej, > > > > On Wed, 19 Jan 2005 05:35:29 +0000 (GMT) > > "Maciej W. Rozycki" wrote: > > > > > On Wed, 19 Jan 2005, Yoichi Yuasa wrote: > > > > > > > > Neither of these uses any CONFIG_* macros. > > > > > > > > I'm making patch for giu.c and icu.c. > > > > These patches need it. > > > > > > Then please just include what you need within these patches. That's the > > > usual way of doing stuff. > > > > Ok, I'll send a patch including get back and add new line. > > Sorry for the delay. > Next I'll send giu.c update. This is giu.c update. Yoichi Signed-off-by: Yoichi Yuasa diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig --- a-orig/arch/mips/vr41xx/Kconfig Tue Mar 8 08:10:16 2005 +++ a/arch/mips/vr41xx/Kconfig Sun Mar 13 23:45:57 2005 @@ -98,7 +98,7 @@ depends on MACH_VR41XX && PCI config GPIO_VR41XX - bool "Add General-purpose I/O unit support of NEC VR4100 series" + tristate "Add General-purpose I/O unit support of NEC VR4100 series" depends on MACH_VR41XX config VRC4171 diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/giu.c a/arch/mips/vr41xx/common/giu.c --- a-orig/arch/mips/vr41xx/common/giu.c Sun Jan 16 22:34:31 2005 +++ a/arch/mips/vr41xx/common/giu.c Thu Mar 17 01:09:47 2005 @@ -3,8 +3,7 @@ * * Copyright (C) 2002 MontaVista Software Inc. * Author: Yoichi Yuasa - * Copyright (C) 2003-2004 Yoichi Yuasa - * Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2003-2005 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -29,6 +28,7 @@ * - Added support for NEC VR4133. * - Removed board_irq_init. */ +#include #include #include #include @@ -63,12 +63,6 @@ static uint32_t giu_base; -static struct irqaction giu_cascade = { - .handler = no_action, - .mask = CPU_MASK_NONE, - .name = "cascade", -}; - #define read_giuint(offset) readw(giu_base + (offset)) #define write_giuint(val, offset) writew((val), giu_base + (offset)) @@ -192,18 +186,20 @@ .end = end_giuint_high_irq, }; -void __init init_vr41xx_giuint_irq(void) +void vr41xx_enable_giuint(unsigned int pin) { - int i; - - for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) { - if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET)) - irq_desc[i].handler = &giuint_low_irq_type; - else - irq_desc[i].handler = &giuint_high_irq_type; - } + if (pin < GIUINT_HIGH_OFFSET) + enable_giuint_low_irq(GIU_IRQ(pin)); + else + enable_giuint_high_irq(GIU_IRQ(pin)); +} - setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade); +void vr41xx_disable_giuint(unsigned int pin) +{ + if (pin < GIUINT_HIGH_OFFSET) + disable_giuint_low_irq(GIU_IRQ(pin)); + else + disable_giuint_high_irq(GIU_IRQ(pin)); } void vr41xx_set_irq_trigger(int pin, int trigger, int hold) @@ -296,6 +292,8 @@ EXPORT_SYMBOL(vr41xx_set_irq_level); +#ifndef MODULE + #define GIUINT_NR_IRQS 32 enum { @@ -310,6 +308,12 @@ static struct vr41xx_giuint_cascade giuint_cascade[GIUINT_NR_IRQS]; +static struct irqaction giu_cascade = { + .handler = no_action, + .mask = CPU_MASK_NONE, + .name = "cascade", +}; + static int no_irq_number(int irq) { return -EINVAL; @@ -421,7 +425,7 @@ enable_irq(GIUINT_CASCADE_IRQ); } -static int __init vr41xx_giu_init(void) +void __init init_vr41xx_giuint_irq(void) { int i; @@ -437,7 +441,7 @@ break; default: printk(KERN_ERR "GIU: Unexpected CPU of NEC VR4100 series\n"); - return -EINVAL; + return; } for (i = 0; i < GIUINT_NR_IRQS; i++) { @@ -449,7 +453,14 @@ giuint_cascade[i].get_irq_number = no_irq_number; } - return 0; + for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) { + if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET)) + irq_desc[i].handler = &giuint_low_irq_type; + else + irq_desc[i].handler = &giuint_high_irq_type; + } + + setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade); } -early_initcall(vr41xx_giu_init); +#endif From brm@murphy.dk Thu Mar 17 21:35:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 21:36:05 +0000 (GMT) Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:37482 "EHLO valis.murphy.dk") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 21:35:49 +0000 Received: from brian.localnet (root@[10.0.0.2]) by valis.murphy.dk (8.13.2/8.13.2/Debian-1) with ESMTP id j2HLZcAG028503; Thu, 17 Mar 2005 22:35:38 +0100 Received: from brian.localnet (brm@localhost [127.0.0.1]) by brian.localnet (8.12.11/8.12.11/Debian-5) with ESMTP id j2HLZcj2006194; Thu, 17 Mar 2005 22:35:38 +0100 Received: (from brm@localhost) by brian.localnet (8.12.11/8.12.11/Debian-5) id j2HLZcFc006193; Thu, 17 Mar 2005 22:35:38 +0100 Date: Thu, 17 Mar 2005 22:35:38 +0100 From: Brian Murphy Message-Id: <200503172135.j2HLZcFc006193@brian.localnet> To: ralf@linux-mips.org Subject: [PATCH 2.6] Lasat cleanups (setup.c) Cc: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brm@murphy.dk Precedence: bulk X-list: linux-mips Content-Length: 1053 Lines: 35 Hi Ralf, long time no see ;-). This is of course because you are doing such a good job of maintaining the Lasat machines kernel code for me. This patch just removes some unused and ancient filler. Please apply. /Brian Index: arch/mips/lasat/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/lasat/setup.c,v retrieving revision 1.15 diff -u -r1.15 setup.c --- arch/mips/lasat/setup.c 14 Jul 2004 16:58:59 -0000 1.15 +++ arch/mips/lasat/setup.c 17 Mar 2005 18:45:44 -0000 @@ -25,7 +25,6 @@ #include #include #include -#include #include #include #include @@ -54,9 +53,6 @@ void lasatint_init(void); extern void lasat_reboot_setup(void); -extern void pcisetup(void); -extern void edhac_init(void *, void *, void *); -extern void addrflt_init(void); struct lasat_misc lasat_misc_info[N_MACHTYPES] = { {(void *)KSEG1ADDR(0x1c840000), (void *)KSEG1ADDR(0x1c800000), 2}, From brm@murphy.dk Thu Mar 17 21:36:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 21:36:46 +0000 (GMT) Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:37738 "EHLO valis.murphy.dk") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 21:36:05 +0000 Received: from brian.localnet (root@[10.0.0.2]) by valis.murphy.dk (8.13.2/8.13.2/Debian-1) with ESMTP id j2HLZtqM028508; Thu, 17 Mar 2005 22:35:55 +0100 Received: from brian.localnet (brm@localhost [127.0.0.1]) by brian.localnet (8.12.11/8.12.11/Debian-5) with ESMTP id j2HLZtI8006207; Thu, 17 Mar 2005 22:35:55 +0100 Received: (from brm@localhost) by brian.localnet (8.12.11/8.12.11/Debian-5) id j2HLZtH0006206; Thu, 17 Mar 2005 22:35:55 +0100 Date: Thu, 17 Mar 2005 22:35:55 +0100 From: Brian Murphy Message-Id: <200503172135.j2HLZtH0006206@brian.localnet> To: ralf@linux-mips.org Subject: [PATCH 2.6] Lasat cleanups (pci-lasat.c) Cc: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brm@murphy.dk Precedence: bulk X-list: linux-mips Content-Length: 3141 Lines: 120 Hi Ralf, this is some formatting fixups (linux coding style) and removal of duplicate and unused headers from the Lasat pci setup code. Please apply. /Brian Index: arch/mips/pci/pci-lasat.c =================================================================== RCS file: /cvs/linux/arch/mips/pci/pci-lasat.c,v retrieving revision 1.8 diff -u -r1.8 pci-lasat.c --- arch/mips/pci/pci-lasat.c 31 Oct 2004 16:07:33 -0000 1.8 +++ arch/mips/pci/pci-lasat.c 17 Mar 2005 21:19:24 -0000 @@ -7,12 +7,8 @@ */ #include #include -#include #include #include -#include -#include -#include #include extern struct pci_ops nile4_pci_ops; @@ -20,14 +16,14 @@ static struct resource lasat_pci_mem_resource = { .name = "LASAT PCI MEM", .start = 0x18000000, - .end = 0x19FFFFFF, + .end = 0x19ffffff, .flags = IORESOURCE_MEM, }; static struct resource lasat_pci_io_resource = { .name = "LASAT PCI IO", .start = 0x1a000000, - .end = 0x1bFFFFFF, + .end = 0x1bffffff, .flags = IORESOURCE_IO, }; @@ -38,21 +34,19 @@ static int __init lasat_pci_setup(void) { - printk("PCI: starting\n"); - - switch (mips_machtype) { - case MACH_LASAT_100: - lasat_pci_controller.pci_ops = >64120_pci_ops; - break; - case MACH_LASAT_200: - lasat_pci_controller.pci_ops = &nile4_pci_ops; - break; - default: - panic("pcibios_init: mips_machtype incorrect"); - } + switch (mips_machtype) { + case MACH_LASAT_100: + lasat_pci_controller.pci_ops = >64120_pci_ops; + break; + case MACH_LASAT_200: + lasat_pci_controller.pci_ops = &nile4_pci_ops; + break; + default: + panic("pcibios_init: mips_machtype incorrect"); + } register_pci_controller(&lasat_pci_controller); - return 0; + return 0; } early_initcall(lasat_pci_setup); @@ -68,24 +62,24 @@ int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { - switch (slot) { - case 1: - return LASATINT_PCIA; /* Expansion Module 0 */ - case 2: - return LASATINT_PCIB; /* Expansion Module 1 */ - case 3: - return LASATINT_PCIC; /* Expansion Module 2 */ - case 4: - return LASATINT_ETH1; /* Ethernet 1 (LAN 2) */ - case 5: - return LASATINT_ETH0; /* Ethernet 0 (LAN 1) */ - case 6: - return LASATINT_HDC; /* IDE controller */ - default: - return 0xff; /* Illegal */ - } + switch (slot) { + case 1: + return LASATINT_PCIA; + case 2: + return LASATINT_PCIB; + case 3: + return LASATINT_PCIC; + case 4: + return LASATINT_ETH1; /* Ethernet 1 (LAN 2) */ + case 5: + return LASATINT_ETH0; /* Ethernet 0 (LAN 1) */ + case 6: + return LASATINT_HDC; /* IDE controller */ + default: + return 0xff; /* Illegal */ + } - return -1; + return -1; } /* Do platform specific device initialization at pci_enable_device() time */ From brm@murphy.dk Thu Mar 17 21:37:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Mar 2005 21:37:29 +0000 (GMT) Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:37994 "EHLO valis.murphy.dk") by linux-mips.org with ESMTP id ; Thu, 17 Mar 2005 21:36:58 +0000 Received: from brian.localnet (root@[10.0.0.2]) by valis.murphy.dk (8.13.2/8.13.2/Debian-1) with ESMTP id j2HLancW028515; Thu, 17 Mar 2005 22:36:49 +0100 Received: from brian.localnet (brm@localhost [127.0.0.1]) by brian.localnet (8.12.11/8.12.11/Debian-5) with ESMTP id j2HLanHd006214; Thu, 17 Mar 2005 22:36:49 +0100 Received: (from brm@localhost) by brian.localnet (8.12.11/8.12.11/Debian-5) id j2HLanro006213; Thu, 17 Mar 2005 22:36:49 +0100 Date: Thu, 17 Mar 2005 22:36:49 +0100 From: Brian Murphy Message-Id: <200503172136.j2HLanro006213@brian.localnet> To: ralf@linux-mips.org Subject: [PATCH 2.6] Lasat pci assignment fixup (pci-lasat.c) (dependant on previous cleanup patch) Cc: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brm@murphy.dk Precedence: bulk X-list: linux-mips Content-Length: 615 Lines: 24 Hi Ralf, this fixes Lasat pci to work with multi-function devices by assigning the correct values based on pin number (instead of ignoring them). And this is of course the real reason for the patches. Please apply. /Brian --- pci-lasat.c 2005-03-17 22:20:56.000000000 +0100 +++ arch/mips/pci/pci-lasat.c 2005-03-17 22:21:21.000000000 +0100 @@ -64,11 +64,9 @@ { switch (slot) { case 1: - return LASATINT_PCIA; case 2: - return LASATINT_PCIB; case 3: - return LASATINT_PCIC; + return LASATINT_PCIA + (((slot-1) + (pin-1)) % 4); case 4: return LASATINT_ETH1; /* Ethernet 1 (LAN 2) */ case 5: From ppopov@embeddedalley.com Fri Mar 18 04:13:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Mar 2005 04:13:22 +0000 (GMT) Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:12635 "HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Fri, 18 Mar 2005 04:13:05 +0000 Received: from unknown (HELO ?192.168.1.102?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp007.bizmail.sc5.yahoo.com with SMTP; 18 Mar 2005 04:13:03 -0000 Message-ID: <423A554D.2080505@embeddedalley.com> Date: Thu, 17 Mar 2005 20:13:01 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: need help with CompactFlash/PCMCIA References: <200503151245.15920.eckhardt@satorlaser.com> <200503161808.10088.eckhardt@satorlaser.com> <42386B0A.5070006@embeddedalley.com> <200503171626.01092.eckhardt@satorlaser.com> In-Reply-To: <200503171626.01092.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 2940 Lines: 70 Ulrich Eckhardt wrote: > Pete Popov wrote: > >>>Looking at EBOOT (a bootloader for win CE that boots off the >>>compactflash), it tries to access the IDE interface at address 0x1a00000 >>>for io_addr and 0x1a00000e for control, let's see if I can find any IDE >>>hardware at that address... >> >>Uhm, I don't think you'll resolve this that easily. There is some code that >>needs to go in the au1x00 socket driver which means you would have to >>understand pretty well how this thing works. Ultimately the addresses >>you'll probe are very high ioremapped addresses, since the pcmcia >>attribute, common mem, and i/o are 36 bit physical addresses. > > > Looking at EBOOT, it creates these mappings here in the TLB: > 0xf 0000 0000 -> 0x1a00 0000 (IO) > 0xf 4000 0000 -> 0x1c00 0000 (attrib) > 0xf 8000 0000 -> 0x1e00 0000 (mem) > each time mapping 32MiB. > In the Linux PCMCIA code, I see that only the IO range above gets ioremap()ed, > and only 4KiB thereof. That's all that's really needed. > For the other two ranges, it uses two addresses that > are intended for use with fixup_bigphys_addr()[1] but seem to target the > equivalent physical addresses as in EBOOT. Correct. The pcmcia stack will call ioremap on those phys addresses when necessary. > I tried simply ioremap()ing the IO region and looked for an ATA interface at > the beginning of that range, but the contents of that memory seem to be > rather random. Well, that's the I/O registers. If you remapped them correctly and you are actually talking to the device, then the data should not be so random. But the attribute memory is a better first test. Hack up the driver to ioremap the attr space after a card is inserted, dump some of that data, and then free the region -- just a simple test to make sure the device is powered and you're actually talking to it. > I'll next try to remove both PCMCIA and IDE drivers, just to > make sure they don't interact in any unforseeable way with my ad-hoc code, > but that's scheduled for tuesday. > I also found www.ata-atapi.com/atadrvr.zip, which contains low-level driver > sourcecode and examples, so I have something to read over the weekend. ;) > > Thank you all for your help! > > Uli > > [1] Why the difference in the handling of the three ranges? Also, what > additional effect does ioremap() have when compared to using the TLB? Is it > that ioremap() is the Right Way(tm) on any architecture Yes. > while TLB is the way that works only on MIPS? No, other processors have TLBs too. I assume you're refering to the yamon vs Linux kernel. Yamon just uses statically setup TLBs to access those addresses. When you call ioremap in the kernel, the kernel will setup the necessary tables to be able to map and handle those phys addresses only when needed. Those TLBs are flushed randomly, and then reentered by the kernel dynamically when needed because of a page fault. Pete From stuartl@longlandclan.hopto.org Fri Mar 18 13:20:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Mar 2005 13:20:51 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:59694 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Fri, 18 Mar 2005 13:20:35 +0000 Received: (qmail 17079 invoked by uid 210); 18 Mar 2005 23:20:25 +1000 Received: from 10.0.0.251 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.251):. Processed in 0.090609 secs); 18 Mar 2005 13:20:25 -0000 Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 18 Mar 2005 23:20:25 +1000 Message-ID: <423AD5A2.3060200@longlandclan.hopto.org> Date: Fri, 18 Mar 2005 23:20:34 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Netbooting CoLo on the Cobalt RaQ1 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig07E3C5EA696A7F17AA2A72F7" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Content-Length: 1736 Lines: 46 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07E3C5EA696A7F17AA2A72F7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, Recently I updated the Gentoo/MIPS Handbook -- in amongst the complete rewrite, was shiny new instructions for how to install Gentoo on a Cobalt server. Now... in the instructions, it asks to download CoLo, extract the colo-chain.elf file, and gzip it up as vmlinux_raq-2800.gz and to put that in /nfsroot on the server. It appears the RaQ1 is a special case, and does not look there to download its kernel. Does anyone know exactly where these boxes look for the kernel image when netbooting? That way, I can ammend[1] the handbook with the new details. Regards, -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ Footnotes: 1. http://bugs.gentoo.org/show_bug.cgi?id=85762 --------------enig07E3C5EA696A7F17AA2A72F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOtWluarJ1mMmSrkRAqCkAJ9Ky0jv19J3MkrBe0a2TM77XOSAoACcC3mw xVqd71DRR+9eNg9DvB6p1Fc= =cY0C -----END PGP SIGNATURE----- --------------enig07E3C5EA696A7F17AA2A72F7-- From tbm@cyrius.com Fri Mar 18 14:12:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Mar 2005 14:12:40 +0000 (GMT) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:783 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Fri, 18 Mar 2005 14:12:25 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id D931664D40; Fri, 18 Mar 2005 14:12:22 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id A3EBF4F29C; Fri, 18 Mar 2005 14:12:08 +0000 (GMT) Date: Fri, 18 Mar 2005 14:12:08 +0000 From: Martin Michlmayr To: Stuart Longland Cc: linux-mips@linux-mips.org Subject: Re: Netbooting CoLo on the Cobalt RaQ1 Message-ID: <20050318141208.GA26486@deprecation.cyrius.com> References: <423AD5A2.3060200@longlandclan.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423AD5A2.3060200@longlandclan.hopto.org> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 540 Lines: 12 * Stuart Longland [2005-03-18 23:20]: > It appears the RaQ1 is a special case, and does not look there to > download its kernel. Does anyone know exactly where these boxes look > for the kernel image when netbooting? That way, I can ammend[1] the > handbook with the new details. Possibly vmlinux_RAQ.gz. In Debian, we have a file called vmlinux.gz and the symlinks vmlinux_raq-2800.gz and vmlinux_RAQ.gz pointing to it, and that seems to work for everyone. -- Martin Michlmayr http://www.cyrius.com/ From macro@linux-mips.org Fri Mar 18 16:23:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Mar 2005 16:23:42 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:21768 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 18 Mar 2005 16:23:24 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id CBF46E1CB6; Fri, 18 Mar 2005 17:23:17 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12482-08; Fri, 18 Mar 2005 17:23:17 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 64A3BE1C98; Fri, 18 Mar 2005 17:23:17 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j2IGNKSV009889; Fri, 18 Mar 2005 17:23:20 +0100 Date: Fri, 18 Mar 2005 16:23:29 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Peter Horton , linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] Cobalt 2/2: add support for Qube2700 In-Reply-To: <20050304151305.GA12169@linux-mips.org> Message-ID: References: <20050301084138.GB2017@skeleton-jack> <20050304151305.GA12169@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/700/Fri Feb 4 00:33:15 2005 clamav-milter version 0.80j on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 222 Lines: 9 On Fri, 4 Mar 2005, Ralf Baechle wrote: > > On Qube2700 Galileo hangs if we access slot #6. > > Patch is ok. Out of curiosity, is the reason known? See my comment about the commit and respective datasheets. Maciej From joseph@omnilux.net Sat Mar 19 01:13:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Mar 2005 01:13:39 +0000 (GMT) Received: from foothill.iad.idealab.com ([IPv6:::ffff:64.208.8.35]:60813 "EHLO foothill.iad.idealab.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 19 Mar 2005 01:13:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: [patch] arch/mips/au1000/common/time.c Date: Fri, 18 Mar 2005 17:13:12 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: time.c fix Thread-Index: AcUsH6MMLEuw/udPSleoURTdhR92NwAAGYow From: "Joseph Chiu" To: , "Ralf Baechle \(E-mail\)" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joseph@omnilux.net Precedence: bulk X-list: linux-mips Content-Length: 965 Lines: 44 Hi, I reported on this a few years ago on 2.4.18, but it never seemed to have been addressed... in linux/arch/mips/au1000/common/time.c, mips_timer_interrupt calls irq_enter() *before* checking if (r4k_offset == 0), and then exits the interrupt without calling irq_exit(). This problem was crashing our boards in some test cases... Please apply. Thanks, Joseph ---- RCS file: /mnt/cvs/kernel-2.6/arch/mips/au1000/common/time.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 time.c *** time.c 13 Mar 2005 08:19:05 -0000 1.1.1.1 --- time.c 19 Mar 2005 01:04:19 -0000 *************** *** 86,96 **** int irq = 63; unsigned long count; - irq_enter(); - kstat_this_cpu.irqs[irq]++; - if (r4k_offset == 0) goto null; do { count = read_c0_count(); --- 86,96 ---- int irq = 63; unsigned long count; if (r4k_offset == 0) goto null; + + irq_enter(); + kstat_this_cpu.irqs[irq]++; do { count = read_c0_count(); From kkojiband@gmail.com Sat Mar 19 08:23:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Mar 2005 08:23:30 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.195]:19083 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Sat, 19 Mar 2005 08:23:15 +0000 Received: by wproxy.gmail.com with SMTP id 37so481237wra for ; Sat, 19 Mar 2005 00:23:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=extK0pzTR7IFOpdC9p4F53s7eqWCCrq8NsYaqey4e4wpgWcbr81xMrclNxbNMsWG2eabM2Smr4Iid0vpG5RgaVDa5rxLPus1G6weJnyemxR4wTpNMs7Ssy0jICvmtkJ70c0JyRjkxas10F1U1NR3dSPlJFwdbmYNLOCCvSL1RsY= Received: by 10.54.11.66 with SMTP id 66mr274235wrk; Sat, 19 Mar 2005 00:23:08 -0800 (PST) Received: by 10.54.47.8 with HTTP; Sat, 19 Mar 2005 00:23:08 -0800 (PST) Message-ID: <61aa49f4050319002332d42f24@mail.gmail.com> Date: Sat, 19 Mar 2005 00:23:08 -0800 From: kim inhyuk Reply-To: kim inhyuk To: linux-mips@linux-mips.org Subject: Do you use 16M ramdisk with kernel-2.4.26?? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kkojiband@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 172 Lines: 11 hi~ i want to use 16M ramdisk... but it fails to decompress ramdisk image... error message is "invalid compressed format (err=1)" please, help me thank you, good day! From nsekhar@ti.com Sat Mar 19 08:58:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Mar 2005 08:58:39 +0000 (GMT) Received: from news.ti.com ([IPv6:::ffff:192.94.94.33]:39935 "EHLO dragon.ti.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 19 Mar 2005 08:58:24 +0000 Received: from dlep91.itg.ti.com ([157.170.152.55]) by dragon.ti.com (8.13.1/8.13.1) with ESMTP id j2J8wJZC020306 for ; Sat, 19 Mar 2005 02:58:19 -0600 (CST) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id j2J8wIFZ019027 for ; Sat, 19 Mar 2005 02:58:18 -0600 (CST) Received: from dlee2k71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j2J8wI74004442 for ; Sat, 19 Mar 2005 02:58:18 -0600 (CST) Received: from dbde2k01.ent.ti.com ([172.24.170.180]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 19 Mar 2005 02:58:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: About PLAT_TRAMPOLINE_STUFF_LINE Date: Sat, 19 Mar 2005 14:26:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About PLAT_TRAMPOLINE_STUFF_LINE Thread-Index: AcUsYYFK2OIenZCYSB67zg2UwXcFrA== From: "Nori, Soma Sekhar" To: X-OriginalArrivalTime: 19 Mar 2005 08:58:18.0074 (UTC) FILETIME=[CB183BA0:01C52C61] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nsekhar@ti.com Precedence: bulk X-list: linux-mips Content-Length: 1973 Lines: 71 Hi, I am porting 2.6.10 (kernel.org) onto a 4kec based board. What should be the value of PLAT_TRAMPOLINE_STUFF_LINE (include/asm-mips/cpu-features.h) for 4kec? If I do not define a cpu-features-overrides.h for my board, this macro is getting set to 0 and as a result signalling code in kernel (arch/mips/kernel/signal.c) seems to break. All my userspace programs using signals are seg faulting. Here is the faulting code: static void inline setup_frame(struct k_sigaction * ka, struct pt_regs *regs, int signr, sigset_t *set) { struct sigframe *frame; int err = 0; frame = get_sigframe(ka, regs, sizeof(*frame)); if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame))) goto give_sigsegv; /* * Set up the return code ... * * li v0, __NR_sigreturn * syscall */ if (PLAT_TRAMPOLINE_STUFF_LINE) __builtin_memset(frame->sf_code, '0', PLAT_TRAMPOLINE_STUFF_LINE); err |= __put_user(0x24020000 + __NR_sigreturn, frame->sf_code + 0); err |= __put_user(0x0000000c , frame->sf_code + 1); flush_cache_sigtramp((unsigned long) frame->sf_code); err |= setup_sigcontext(regs, &frame->sf_sc); err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set)); if (err) goto give_sigsegv; ... With PLAT_TRAMPOLINE_STUFF_LINE set to 0, get_sigframe always returns 0 and setup_frame sends a SIGSEGV because __put_user returns an error value. When I override the value of PLAT_TRAMPOLINE_STUFF_LINE to 16 (the cache line size of the 4kec), the signalling code seems to work just fine. (None of my userspace programs crash anymore). This macro does not seem to be overridden for most boards, so 0 must be a valid value for atleast some MIPS CPUs. Am I right in changing the value of PLAT_TRAMPOLINE_STUFF_LINE to 16? A google search on this macro did not yield much information. Any help/pointers regarding this is greatly appreciated. Thanks, Sekhar Nori. From stuartl@longlandclan.hopto.org Sat Mar 19 14:30:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Mar 2005 14:30:49 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:12841 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Sat, 19 Mar 2005 14:30:33 +0000 Received: (qmail 16578 invoked by uid 210); 20 Mar 2005 00:30:21 +1000 Received: from 10.0.0.251 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.251):. Processed in 0.112162 secs); 19 Mar 2005 14:30:21 -0000 Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 20 Mar 2005 00:30:20 +1000 Message-ID: <423C3787.6090107@longlandclan.hopto.org> Date: Sun, 20 Mar 2005 00:30:31 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Netbooting CoLo on the Cobalt RaQ1 References: <423AD5A2.3060200@longlandclan.hopto.org> <20050318141208.GA26486@deprecation.cyrius.com> In-Reply-To: <20050318141208.GA26486@deprecation.cyrius.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14A63D519915E491327B3084" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Content-Length: 2286 Lines: 54 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14A63D519915E491327B3084 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Martin Michlmayr wrote: > * Stuart Longland [2005-03-18 23:20]: > >> It appears the RaQ1 is a special case, and does not look there to >>download its kernel. Does anyone know exactly where these boxes look >>for the kernel image when netbooting? That way, I can ammend[1] the >>handbook with the new details. > > > Possibly vmlinux_RAQ.gz. In Debian, we have a file called vmlinux.gz > and the symlinks vmlinux_raq-2800.gz and vmlinux_RAQ.gz pointing to > it, and that seems to work for everyone. Hi, Thanks for the reply. I thought this might be the case. I suspect something weird is going on firmware wise. When this user tries to boot, the system reports back "Unknown Compression Method". A full log from the serial console is here: . I suspect the system, as the colo-chain.elf is simply gzipped and named 'vmlinux.gz'. We also get the same error message when using the Debian netboot images -- which is interesting to say the least. I've looked around but haven't seen any comments regarding Gentoo or Debian on a RaQ1. Has anyone tried installing a modern Linux distribution on these boxes? -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ --------------enig14A63D519915E491327B3084 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCPDeKuarJ1mMmSrkRAiyuAJwJm8ELY60ZJjPOqpP+Qob8ZXJMMgCeKPWc tDZlpyHiElS0ACU5uHwDDco= =I0// -----END PGP SIGNATURE----- --------------enig14A63D519915E491327B3084-- From tbm@cyrius.com Sun Mar 20 11:56:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 11:56:53 +0000 (GMT) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:32782 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 11:56:38 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 6EB3E64D3D; Sun, 20 Mar 2005 11:56:35 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 175354ECF5; Sun, 20 Mar 2005 11:56:25 +0000 (GMT) Date: Sun, 20 Mar 2005 11:56:25 +0000 From: Martin Michlmayr To: Stuart Longland Cc: linux-mips@linux-mips.org Subject: Re: Netbooting CoLo on the Cobalt RaQ1 Message-ID: <20050320115624.GB20242@deprecation.cyrius.com> References: <423AD5A2.3060200@longlandclan.hopto.org> <20050318141208.GA26486@deprecation.cyrius.com> <423C3787.6090107@longlandclan.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423C3787.6090107@longlandclan.hopto.org> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 982 Lines: 21 * Stuart Longland [2005-03-20 00:30]: > When this user tries to boot, the system reports back "Unknown > Compression Method". A full log from the serial console is here: > . I suspect the system, as > the colo-chain.elf is simply gzipped and named 'vmlinux.gz'. Yes, gzipped with -9 (although I'm not sure whether this is a requirement or just used to save space). > We also get the same error message when using the Debian netboot > images > -- which is interesting to say the least. I've looked around but > haven't seen any comments regarding Gentoo or Debian on a RaQ1. Has > anyone tried installing a modern Linux distribution on these boxes? I don't know anyone who explicitly said they're running on a RaQ1 but I've never heard of problems either (until now). A Debian person might be getting a RaQ1 soon so we'll see whether it works for him. -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Sun Mar 20 16:29:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 16:30:00 +0000 (GMT) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:12306 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 16:29:46 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id BC27864D3C; Sun, 20 Mar 2005 16:29:42 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 5CE614EC54; Sun, 20 Mar 2005 16:29:30 +0000 (GMT) Date: Sun, 20 Mar 2005 16:29:30 +0000 From: Martin Michlmayr To: Stuart Longland Cc: linux-mips@linux-mips.org Subject: Re: Netbooting CoLo on the Cobalt RaQ1 Message-ID: <20050320162930.GA6007@deprecation.cyrius.com> References: <423AD5A2.3060200@longlandclan.hopto.org> <20050318141208.GA26486@deprecation.cyrius.com> <423C3787.6090107@longlandclan.hopto.org> <20050320115624.GB20242@deprecation.cyrius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050320115624.GB20242@deprecation.cyrius.com> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 422 Lines: 10 * tbm [2005-03-20 11:56]: > I don't know anyone who explicitly said they're running on a RaQ1 but > I've never heard of problems either (until now). A Debian person > might be getting a RaQ1 soon so we'll see whether it works for him. I just reconfirmed with someone and the successful installation report in http://bugs.debian.org/287321 was done on a RaQ1. -- Martin Michlmayr http://www.cyrius.com/ From brm@murphy.dk Sun Mar 20 19:44:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 19:45:02 +0000 (GMT) Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:62319 "EHLO valis.murphy.dk") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 19:44:47 +0000 Received: from brian.localnet (root@[10.0.0.2]) by valis.murphy.dk (8.13.2/8.13.2/Debian-1) with ESMTP id j2KJibRW031585; Sun, 20 Mar 2005 20:44:37 +0100 Received: from brian.localnet (brm@localhost [127.0.0.1]) by brian.localnet (8.12.11/8.12.11/Debian-5) with ESMTP id j2KJibug021626; Sun, 20 Mar 2005 20:44:37 +0100 Received: (from brm@localhost) by brian.localnet (8.12.11/8.12.11/Debian-5) id j2KJiaPc021625; Sun, 20 Mar 2005 20:44:36 +0100 Date: Sun, 20 Mar 2005 20:44:36 +0100 From: Brian Murphy Message-Id: <200503201944.j2KJiaPc021625@brian.localnet> To: ralf@linux-mips.org Subject: [PATCH] R43XX tlb write entry missing Cc: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brm@murphy.dk Precedence: bulk X-list: linux-mips Content-Length: 504 Lines: 21 Hi Ralf, the R43XX is missing an entry in the tlbw synthesizer. Here is a patch. /Brian Index: arch/mips/mm/tlbex.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/tlbex.c,v retrieving revision 1.17 diff -u -r1.17 tlbex.c --- arch/mips/mm/tlbex.c 1 Mar 2005 06:33:17 -0000 1.17 +++ arch/mips/mm/tlbex.c 17 Mar 2005 23:14:44 -0000 @@ -830,6 +830,7 @@ i_nop(p); break; + case CPU_R4300: case CPU_R4600: case CPU_R4700: case CPU_R5000: From ralf@linux-mips.org Sun Mar 20 22:16:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 22:16:42 +0000 (GMT) Received: from p3EE2BB7C.dip.t-dialin.net ([IPv6:::ffff:62.226.187.124]:36480 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 22:16:24 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2KMF0i9007106; Sun, 20 Mar 2005 22:15:00 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2KMEx6k007105; Sun, 20 Mar 2005 22:14:59 GMT Date: Sun, 20 Mar 2005 22:14:59 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux Message-ID: <20050320221459.GA6727@linux-mips.org> References: <20050115013112Z8225557-1340+1316@linux-mips.org> <20050119134211.2c0e24f5.yuasa@hh.iij4u.or.jp> <20050119143146.09982d63.yuasa@hh.iij4u.or.jp> <20050119152151.7b756560.yuasa@hh.iij4u.or.jp> <20050308014420.6253f8ce.yuasa@hh.iij4u.or.jp> <20050318004750.01b33b9e.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050318004750.01b33b9e.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 132 Lines: 9 On Fri, Mar 18, 2005 at 12:47:50AM +0900, Yoichi Yuasa wrote: > This is giu.c update. > > Yoichi Thanks Yoichi, applied. Ralf From ralf@linux-mips.org Sun Mar 20 22:42:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 22:42:25 +0000 (GMT) Received: from p3EE066C8.dip.t-dialin.net ([IPv6:::ffff:62.224.102.200]:63872 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 22:42:10 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2KMeVbC008285; Sun, 20 Mar 2005 22:40:31 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2KMeTha008284; Sun, 20 Mar 2005 22:40:29 GMT Date: Sun, 20 Mar 2005 22:40:29 +0000 From: Ralf Baechle To: Andrew Morton Cc: Russell King , linux-kernel@vger.kernel.org, Pete Popov , linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Message-ID: <20050320224028.GB6727@linux-mips.org> References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050319141351.74f6b2a5.akpm@osdl.org> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1329 Lines: 39 On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote: > > au1x00_uart > > ----------- > > > > Maintainer: unknown (akpm - any ideas?) > > Ralf. Actually Pete Popov (ppopov@embeddedalley.com) who I put on the cc. > > This is a complete clone of 8250.c, which includes all the 8250-specific > > structure names. > > > > Specifically, I'd like to see the following addressed: > > > > - Please clean this up to use au1x00-specific names. > > - this driver is lagging behind with fixes that the other drivers are > > getting. Is au1x00_uart actually maintained? Sort of; much of the Alchemy development effort is still going into 2.4. > > - the usage of UPIO_HUB6 > > (this driver doesn't support hub6 cards) > > - __register_serial, register_serial, unregister_serial > > (this driver doesn't support PCMCIA cards, all of which are based on > > 8250-compatible devices.) > > - early_serial_setup > > (should we really have the function name duplicated across different > > hardware drivers?) No argument here. Pete says the AMD Alchemy UART is just different enough to be hard to handle in the 8250 and so the driver is just an ugly chainsawed version of the 8250.c > > The main reason is I wish to kill off uart_register_port and > > uart_unregister_port, but these drivers are using it. Ralf From ralf@linux-mips.org Sun Mar 20 22:43:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 22:43:38 +0000 (GMT) Received: from p3EE066C8.dip.t-dialin.net ([IPv6:::ffff:62.224.102.200]:2689 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 22:43:23 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2KMg54g014935; Sun, 20 Mar 2005 22:42:05 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2KMg5mT014891; Sun, 20 Mar 2005 22:42:05 GMT Date: Sun, 20 Mar 2005 22:42:05 +0000 From: Ralf Baechle To: Brian Murphy Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] R43XX tlb write entry missing Message-ID: <20050320224205.GC6727@linux-mips.org> References: <200503201944.j2KJiaPc021625@brian.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503201944.j2KJiaPc021625@brian.localnet> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 254 Lines: 10 On Sun, Mar 20, 2005 at 08:44:36PM +0100, Brian Murphy wrote: > Hi Ralf, > the R43XX is missing an entry in the tlbw synthesizer. > Here is a patch. Are you testing on a R4300 series processor? I think I've not had any test reports in years. Ralf From ppopov@embeddedalley.com Sun Mar 20 22:51:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 22:51:59 +0000 (GMT) Received: from smtp004.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.81]:20910 "HELO smtp004.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Sun, 20 Mar 2005 22:51:43 +0000 Received: from unknown (HELO ?192.168.1.102?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 20 Mar 2005 22:51:41 -0000 Message-ID: <423DFE7C.7040406@embeddedalley.com> Date: Sun, 20 Mar 2005 14:51:40 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Andrew Morton , Russell King , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> <20050320224028.GB6727@linux-mips.org> In-Reply-To: <20050320224028.GB6727@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1738 Lines: 54 Ralf Baechle wrote: > On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote: > > >>>au1x00_uart >>>----------- >>> >>>Maintainer: unknown (akpm - any ideas?) >> >>Ralf. > > > Actually Pete Popov (ppopov@embeddedalley.com) who I put on the cc. Thanks :) >>>This is a complete clone of 8250.c, which includes all the 8250-specific >>>structure names. >>> >>>Specifically, I'd like to see the following addressed: >>> >>>- Please clean this up to use au1x00-specific names. >>>- this driver is lagging behind with fixes that the other drivers are >>> getting. Is au1x00_uart actually maintained? > > > Sort of; much of the Alchemy development effort is still going into 2.4. It works and no one has complained about any bugs. But you're right, fixes going into other drivers have not made it into this one. >>>- the usage of UPIO_HUB6 >>> (this driver doesn't support hub6 cards) >>>- __register_serial, register_serial, unregister_serial >>> (this driver doesn't support PCMCIA cards, all of which are based on >>> 8250-compatible devices.) >>>- early_serial_setup >>> (should we really have the function name duplicated across different >>> hardware drivers?) > > > No argument here. Pete says the AMD Alchemy UART is just different enough > to be hard to handle in the 8250 and so the driver is just an ugly > chainsawed version of the 8250.c > > >>>The main reason is I wish to kill off uart_register_port and >>>uart_unregister_port, but these drivers are using it. I tried a couple of times to cleanly add support to the 8250 for the Au1x serial. The uart is just different enough to make that hard, though I admit I never spent too much time on it. Sounds like it's time to revisit it again. Pete From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Sun Mar 20 23:24:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 23:25:04 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([IPv6:::ffff:212.18.232.186]:29201 "EHLO caramon.arm.linux.org.uk") by linux-mips.org with ESMTP id ; Sun, 20 Mar 2005 23:24:48 +0000 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1DD9mi-0006x8-3O; Sun, 20 Mar 2005 23:24:40 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.41) id 1DD9mh-0000OC-0W; Sun, 20 Mar 2005 23:24:39 +0000 Date: Sun, 20 Mar 2005 23:24:38 +0000 From: Russell King To: Pete Popov Cc: Ralf Baechle , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Message-ID: <20050320232438.B31657@flint.arm.linux.org.uk> Mail-Followup-To: Pete Popov , Ralf Baechle , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> <20050320224028.GB6727@linux-mips.org> <423DFE7C.7040406@embeddedalley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <423DFE7C.7040406@embeddedalley.com>; from ppopov@embeddedalley.com on Sun, Mar 20, 2005 at 02:51:40PM -0800 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmk+lkml@arm.linux.org.uk Precedence: bulk X-list: linux-mips Content-Length: 767 Lines: 19 On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote: > >>>- __register_serial, register_serial, unregister_serial > >>> (this driver doesn't support PCMCIA cards, all of which are based on > >>> 8250-compatible devices.) > > I tried a couple of times to cleanly add support to the 8250 for the Au1x > serial. The uart is just different enough to make that hard, though I admit I > never spent too much time on it. Sounds like it's time to revisit it again. I would prefer to have a patch to remove (or ack to do so myself) the above three mentioned functions so I can avoid breaking your driver, rather than a large update to it. Thanks. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core From ppopov@embeddedalley.com Sun Mar 20 23:42:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Mar 2005 23:42:45 +0000 (GMT) Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:27000 "HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Sun, 20 Mar 2005 23:42:30 +0000 Received: from unknown (HELO ?192.168.1.102?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp007.bizmail.sc5.yahoo.com with SMTP; 20 Mar 2005 23:42:27 -0000 Message-ID: <423E0A63.7050802@embeddedalley.com> Date: Sun, 20 Mar 2005 15:42:27 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell King CC: Ralf Baechle , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> <20050320224028.GB6727@linux-mips.org> <423DFE7C.7040406@embeddedalley.com> <20050320232438.B31657@flint.arm.linux.org.uk> In-Reply-To: <20050320232438.B31657@flint.arm.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 786 Lines: 22 Russell King wrote: > On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote: > >>>>>- __register_serial, register_serial, unregister_serial >>>>> (this driver doesn't support PCMCIA cards, all of which are based on >>>>> 8250-compatible devices.) >> >>I tried a couple of times to cleanly add support to the 8250 for the Au1x >>serial. The uart is just different enough to make that hard, though I admit I >>never spent too much time on it. Sounds like it's time to revisit it again. > > > I would prefer to have a patch to remove (or ack to do so myself) the > above three mentioned functions so I can avoid breaking your driver, > rather than a large update to it. Go for it. I'll test the driver afterwards and think about getting it into the 8250 again. Thanks, Pete From michael@cubic.org Mon Mar 21 08:18:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 08:19:10 +0000 (GMT) Received: from d062149.adsl.hansenet.de ([IPv6:::ffff:80.171.62.149]:27667 "EHLO gruft.cubic.org") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 08:18:55 +0000 Received: from cubic.org (starbase [192.168.10.1]) by gruft.cubic.org (8.12.2/8.12.2) with ESMTP id j2L8Iqm9029305 for ; Mon, 21 Mar 2005 09:18:53 +0100 Message-ID: <423E7B9D.3040908@cubic.org> Date: Mon, 21 Mar 2005 08:45:33 +0100 From: Michael Stickel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> <20050320224028.GB6727@linux-mips.org> In-Reply-To: <20050320224028.GB6727@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michael@cubic.org Precedence: bulk X-list: linux-mips Content-Length: 745 Lines: 24 Ralf Baechle wrote: >On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote: > > >No argument here. Pete says the AMD Alchemy UART is just different enough >to be hard to handle in the 8250 and so the driver is just an ugly >chainsawed version of the 8250.c > > Even if I don't make me a lot of friends, the au1x00 driver seems to be a hack. Most of the difference seems to be the PCI stuff, that has been removed and the access method. Shouldn't we have a driver for the chip and one driver for each access method (isa,pci,...). The access method should handle register access and the bus abstraction. I have a lot of problems with the au1x00 serial driver, because I use it together with a PCMCIA serial port card. Michael From tully@mikrotik.com Mon Mar 21 08:25:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 08:25:31 +0000 (GMT) Received: from frog.mt.lv ([IPv6:::ffff:159.148.172.197]:18364 "EHLO frog.mt.lv") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 08:25:16 +0000 Received: from [10.0.0.231] (helo=your-lnsz0iqs6f.mikrotik.com) by frog.mt.lv with esmtp (Exim 4.44) id 1DDIEp-00054a-Te for linux-mips@linux-mips.org; Mon, 21 Mar 2005 10:26:15 +0200 Message-Id: <6.2.1.2.0.20050321102413.04f4f0e0@frog.mt.lv> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 10:25:23 +0200 To: linux-mips@linux-mips.org From: John Tully Subject: Low cost MIPS board for APs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tully@mikrotik.com Precedence: bulk X-list: linux-mips Content-Length: 206 Lines: 8 Here is a review of a new low cost mips board we made that includes a SDK. http://www.linuxdevices.com/news/NS9341546150.html John www.mikrotik.com From sskowron@ET.PUT.Poznan.PL Mon Mar 21 09:06:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 09:06:43 +0000 (GMT) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:54775 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 09:06:28 +0000 Received: from athena (athena.et.put.poznan.pl [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j2L96Ql04130; Mon, 21 Mar 2005 10:06:26 +0100 (MET) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Mon, 21 Mar 2005 10:06:26 +0100 (MET) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j2L96KC17596; Mon, 21 Mar 2005 10:06:20 +0100 (MET) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Mon, 21 Mar 2005 10:06:20 +0100 (MET) From: Stanislaw Skowronek To: Michael Stickel cc: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers In-Reply-To: <423E7B9D.3040908@cubic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Content-Length: 320 Lines: 11 > Most of the difference seems to be the PCI stuff, that has been removed > and the access method. > Shouldn't we have a driver for the chip and one driver for each access > method (isa,pci,...). Right! I'm entirely with you. SGI Octane required hacks to the 8250 driver just to get a new access method. Stanislaw From ppopov@embeddedalley.com Mon Mar 21 09:19:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 09:20:05 +0000 (GMT) Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:19097 "HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Mon, 21 Mar 2005 09:19:50 +0000 Received: from unknown (HELO ?192.168.1.102?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp002.bizmail.yahoo.com with SMTP; 21 Mar 2005 09:19:47 -0000 Message-ID: <423E91B3.4000302@embeddedalley.com> Date: Mon, 21 Mar 2005 01:19:47 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Stickel CC: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050319141351.74f6b2a5.akpm@osdl.org> <20050320224028.GB6727@linux-mips.org> <423E7B9D.3040908@cubic.org> In-Reply-To: <423E7B9D.3040908@cubic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 525 Lines: 15 > Even if I don't make me a lot of friends, the au1x00 driver seems to be > a hack. Well, it basically is. > Most of the difference seems to be the PCI stuff, that has been removed > and the access method. There were a bunch of differences including how you program the baud rate, the addresses of the registers, and if I remember correctly, additional/different registers. To cleanly get the au1x support into the 8250 driver, some additional abstraction was necessary and I just never had the time to do it. Pete From michael.stickel@4g-systems.biz Mon Mar 21 12:12:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 12:12:26 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.191]:13040 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 12:12:11 +0000 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDLlR-0002o8-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 13:12:09 +0100 Received: from [217.91.102.65] (helo=create.4g) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDLlR-0000YN-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 13:12:09 +0100 From: Michael Stickel To: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Date: Mon, 21 Mar 2005 13:12:08 +0100 User-Agent: KMail/1.7 References: <20050319172101.C23907@flint.arm.linux.org.uk> <423E7B9D.3040908@cubic.org> <423E91B3.4000302@embeddedalley.com> In-Reply-To: <423E91B3.4000302@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503211312.08970.michael.stickel@4g-systems.biz> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f72049c8971f462876d14eb8b3ccbbf1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michael.stickel@4g-systems.biz Precedence: bulk X-list: linux-mips Content-Length: 1153 Lines: 27 On Monday 21 March 2005 10:19, Pete Popov wrote: > There were a bunch of differences including how you program the baud rate, You mentioned the baudrate. There is one thing that had happend to me. On the au1x00 the baud_base is 0 by default. In the serial driver there is a division by baud_base, that ends up in a an exception. How could we handle that. For the moment I set it to a default before it is used: if (baud_base == 0L) baud_base = 115200; Which is also a hack. How can we get the correct baud_base for a pcmcia based serial-port. > the addresses of the registers, and if I remember correctly, > additional/different registers. To cleanly get the au1x support into the > 8250 driver, some additional abstraction was necessary and I just never had > the time to do it. We should have a resource for the register access and the serial driver should not care about what it is (memory,io,au1x00,multiport,...). It should just use the resource to access the chip. The resource can be a "virtual resource" like the multiport cards that have an index register. The serial port needs a second resource that is the interrupt. Michael From ralf@linux-mips.org Mon Mar 21 12:40:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 12:40:27 +0000 (GMT) Received: from p3EE066C8.dip.t-dialin.net ([IPv6:::ffff:62.224.102.200]:47005 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 12:40:12 +0000 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2LCclVO016803; Mon, 21 Mar 2005 12:38:47 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2LCckVm016801; Mon, 21 Mar 2005 12:38:46 GMT Date: Mon, 21 Mar 2005 12:38:46 +0000 From: Ralf Baechle To: Michael Stickel Cc: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Message-ID: <20050321123846.GA10699@linux-mips.org> References: <20050319172101.C23907@flint.arm.linux.org.uk> <423E7B9D.3040908@cubic.org> <423E91B3.4000302@embeddedalley.com> <200503211312.08970.michael.stickel@4g-systems.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503211312.08970.michael.stickel@4g-systems.biz> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 229 Lines: 7 On Mon, Mar 21, 2005 at 01:12:08PM +0100, Michael Stickel wrote: It would be useful if you had not truncated the cc list of this thread. The people that deciede on the serial drivers fate are now no longer receiving it. Ralf From maillist@jg555.com Mon Mar 21 16:34:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 16:34:21 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:20879 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 16:34:05 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 21 Mar 2005 08:34:03 -0800 id 0000847B.423EF77B.00000D53 Message-ID: <423EF764.1070305@jg555.com> Date: Mon, 21 Mar 2005 08:33:40 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: Re: Current Build Warning Message References: <42375617.3020002@jg555.com> <20050315215538.GJ6025@linux-mips.org> <423EF440.9090902@jg555.com> In-Reply-To: <423EF440.9090902@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 4826 Lines: 141 Jim Gifford wrote: FYI for the list. Didn't mean to send to you excusively Ralf, sorry. Ralf, Got that one fixed, everything compiles ok. But now on bootup I get this. If you need it, I can give you ssh access to a RaQ2 to work with. Let me know. Cobalt Microserver Diagnostics - 'We serve it, you surf it' Built Wed Mar 3 21:26:25 PST 1999 1.LCD Test................................PASS 2.Controller Test.........................PASS 5.Bank 0:.................................64M 6.Bank 1:.................................64M 7.Bank 2:.................................64M 8.Bank 3:.................................64M 9.Serial Test.............................PASS 10.PCI Expansion Slot....................**EMPTY** 12.IDE Test................................PASS 13.Ethernet Test...........................PASS 16.RTC Test................................PASS BOOTLOADER: trying to boot from partition /dev/hda1 Decompressing done Decompressing done. [ "CoLo" v1.17 ] stage2: 8ffa0000-90000000 cpu: clock 250.000MHz pci: unit type tulip: #0 device 21143 tulip: #1 device 21143 tulip: {00:10:e0:00:33:94} ide: resetting boot: running boot menu 1> lcd 'Booting...' 1> mount ide: {HDS722580VLAT20} ide: LBA48 156250000 ide: supports PIO mode 4 ide: mode 4 timing ide: partition 1 ext2: revision 0 1> lcd 'Booting...' /dev/{mounted-volume} 1> -load /boot/default.colo ext2: {boot/default.colo} --> {./default.colo} 000002f6 758t 1> -script 2> var _image vmlinux-2.6.11.5-jg-1.gz 2> var _console '' 2> -var _console console=ttyS0,{console-speed} 2> -noop {menu-option} 2> select 'BOOT KERNEL' 100 2.6.11.5-jg-1 2.6.11.4-jg-1 2.6.9-jg-2 2.6.9 vmlinux.old 2> goto {menu-option} 2> lcd 'Loading ...' {_image} 2> mount ide: partition 1 ext2: revision 0 2> cd /boot ext2: {boot} --> {.} / 2> load {_image} 0013161a 1250842t 2> execute root=/dev/hda2 {_console} ide1=noprobe elf32: 00080000 - 0032401f (802f1000) (ffffffff.80000000) elf32: 80080000 (80080000) 2670725t + 98203t Linux version 2.6.11.5-jg-1 (root@lfs) (gcc version 3.4.3) #1 Sun Mar 20 01:22:16 PST 2005 CPU revision is: 000028a0 FPU revision is: 000028a0 Cobalt board ID: 6 Determined physical RAM map: memory: 10000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: root=/dev/hda2 console=ttyS0,115200 ide1=noprobe ide_setup: ide1=noprobe Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. Synthesized TLB refill handler (21 instructions). Synthesized TLB load handler fastpath (34 instructions). Synthesized TLB store handler fastpath (34 instructions). Synthesized TLB modify handler fastpath (33 instructions). PID hash table entries: 2048 (order: 11, 32768 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256256k/262144k available (2074k kernel code, 5692k reserved, 421k data, 112k init, 0k highmem) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Checking for 'wait' instruction... available. NET: Registered protocol family 16 Galileo ID: 17 Activating ISA DMA hang workarounds. Break instruction in kernel code in arch/mips/kernel/traps.c::do_bp, line 560[#1]: Cpu 0 $ 0 : 00000000 90004400 00000000 10000000 $ 4 : 80350008 803142f4 fffb6ced 80310000 $ 8 : 10000000 00000008 80310000 80310000 $12 : 80310000 00100100 00200200 812a6674 $16 : 000005af 000005af 8126bb78 90004401 $20 : 802b1fb8 fffffa51 80310000 0000003c $24 : 812a667c 00000000 $28 : 80350000 80351de0 80351de0 80081338 Hi : 00000000 Lo : 00000000 epc : 802833f0 Not tainted ra : 80081338 Status: 90004402 KERNEL EXL Cause : 00808024 PrId : 000028a0 Modules linked in: Process swapper (pid: 1, threadinfo=80350000, task=8126bb78) Stack : 802b1fb8 80080a30 000005af 800ae97c 000005af 000005af 802b0000 0000003e 80081338 800dd5d8 8126bb78 00000000 802b37fc 800d8038 0000000d e0000000 00000000 90004400 80310000 802e7bc0 000005af 000005af 00000001 803186a4 000005af 802b1fb8 80310000 80310000 80310000 00100100 00200200 812a6674 000005af 000005af 802b0000 90004401 802b1fb8 fffffa51 80310000 0000003c ... Call Trace: [<80080a30>] [<800ae97c>] [<80081338>] [<800dd5d8>] [<800d8038>] [<800a6c18>] [<800a70c4>] <800a70e0>] [<800a75a0>] [<801cb638>] [<80113424>] [<801a8d28>] [<800a7738>] [<801a829c>] <801a9614>] [<801a7220>] [<80080538>] [<80082d9c>] [<80082d8c>]> Code: 8fb00010 03e00008 27bd0028 <0200000d> 080a0cd9 8f820010 27bdffb0 afbe0048 afb00040 Kernel panic - not syncing: Attempted to kill init! -- ---- Jim Gifford maillist@jg555.com From maillist@jg555.com Mon Mar 21 19:51:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 19:51:51 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:45718 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 19:51:35 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 21 Mar 2005 11:51:32 -0800 id 0000C3B3.423F25C4.00000253 Message-ID: <423F25AD.6030705@jg555.com> Date: Mon, 21 Mar 2005 11:51:09 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: Linux MIPS List Subject: Re: Current Build Warning Message References: <42375617.3020002@jg555.com> <20050315215538.GJ6025@linux-mips.org> <423EF440.9090902@jg555.com> <423EF764.1070305@jg555.com> In-Reply-To: <423EF764.1070305@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 2981 Lines: 83 Ralf, Here are the warnings with ksym working. Linux version 2.6.11.5-jg-2 (root@lfs) (gcc version 3.4.3) #1 Mon Mar 21 11:07:30 PST 2005 CPU revision is: 000028a0 FPU revision is: 000028a0 Cobalt board ID: 6 Determined physical RAM map: memory: 10000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: root=/dev/hda2 console=ttyS0,115200 ide1=noprobe ide_setup: ide1=noprobe Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. Synthesized TLB refill handler (21 instructions). Synthesized TLB load handler fastpath (34 instructions). Synthesized TLB store handler fastpath (34 instructions). Synthesized TLB modify handler fastpath (33 instructions). PID hash table entries: 2048 (order: 11, 32768 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256000k/262144k available (2079k kernel code, 5940k reserved, 664k data, 112k init, 0k highmem) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Checking for 'wait' instruction... available. Break instruction in kernel code in arch/mips/kernel/traps.c::do_bp, line 560[#1]: Cpu 0 $ 0 : 00000000 90004400 00000000 10000000 $ 4 : 802b0008 80352164 fffb6cbb 80350000 $ 8 : 10000000 00000008 80350000 00008000 $12 : 7fffffff 00100100 00200200 7fffffff $16 : 80082958 afff62a8 802b2000 00000001 $20 : 8ffa0000 8ffc0000 8ffc0000 00000000 $24 : 00000000 802b1e23 $28 : 802b0000 802b1e78 802b1e78 80081338 Hi : 000f41fa Lo : 2fc92280 epc : 802849b0 preempt_schedule_irq+0xcc/0xd8 Not tainted ra : 80081338 ret_from_fork+0x0/0x8 Status: 90004402 KERNEL EXL Cause : 00808024 PrId : 000028a0 Modules linked in: Process swapper (pid: 0, threadinfo=802b0000, task=802b2000) Stack : 8ffa0000 80080a30 80082958 800ae97c 80082958 afff62a8 00000000 802b1f50 80081338 80080470 00000a00 00000001 8ffa0000 8ffc0000 80082e18 80363274 00000000 90004400 efffffff 802b0008 802b9430 802b2000 00000000 0000001d 802b1f80 81291f30 00008000 00008000 7fffffff 00100100 00200200 7fffffff 80082958 afff62a8 00000000 00000001 8ffa0000 8ffc0000 8ffc0000 00000000 ... Call Trace: [<80080a30>] cobalt_irq+0x170/0x240 [<80082958>] cpu_idle+0x48/0x50 [<800ae97c>] irq_exit+0x5c/0x74 [<80082958>] cpu_idle+0x48/0x50 [<80081338>] ret_from_fork+0x0/0x8 [<80080470>] init+0x0/0x270 [<80082e18>] kernel_thread+0x74/0x8c [<80082958>] cpu_idle+0x48/0x50 [<80082958>] cpu_idle+0x48/0x50 [<80283dc0>] schedule+0x4c/0xacc [<80082958>] cpu_idle+0x48/0x50 [<8019e514>] idr_cache_ctor+0x0/0xc [<8032f764>] start_kernel+0x1b4/0x25c [<8032f0fc>] unknown_bootoption+0x0/0x310 Code: 8fb00010 03e00008 27bd0028 <0200000d> 080a1249 8f820010 27bdffb0 afbe0048 afb00040 Kernel panic - not syncing: Attempted to kill the idle task -- ---- Jim Gifford maillist@jg555.com From maillist@jg555.com Mon Mar 21 20:00:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 20:00:51 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:5783 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 20:00:35 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 21 Mar 2005 12:00:32 -0800 id 0000C3B3.423F27E0.000003EA Message-ID: <423F27C9.4090909@jg555.com> Date: Mon, 21 Mar 2005 12:00:09 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ralf@linux-mips.org CC: Linux MIPS List Subject: Re: Current Build Warning Message References: <42375617.3020002@jg555.com> <20050315215538.GJ6025@linux-mips.org> <423EF440.9090902@jg555.com> <423EF764.1070305@jg555.com> <423F25AD.6030705@jg555.com> In-Reply-To: <423F25AD.6030705@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 3835 Lines: 107 Here is the output of ksymoops. ksymoops 2.4.11 on mips 2.6.9-jg-2. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -L (specified) -o /lib/modules/2.6.11.5-jg-2/ (specified) -m /boot/System-2.6.11.5-jg-2.map (specified) No modules in ksyms, skipping objects 000002ae 686t 0014ea7f 1370751t Cpu 0 $ 0 : 00000000 90004400 00000000 10000000 $ 4 : 802b0008 80352164 fffb6cbb 80350000 $ 8 : 10000000 00000008 80350000 00008000 $12 : 7fffffff 00100100 00200200 7fffffff $16 : 80082958 afff62a8 802b2000 00000001 $20 : 8ffa0000 8ffc0000 8ffc0000 00000000 $24 : 00000000 802b1e23 $28 : 802b0000 802b1e78 802b1e78 80081338 Hi : 000f41fa Lo : 2fc92280 epc : 802849b0 preempt_schedule_irq+0xcc/0xd8 Not tainted Using defaults from ksymoops -t elf32-tradlittlemips -a mips:8000 Status: 90004402 KERNEL EXL Cause : 00808024 80081338 80080470 00000a00 00000001 8ffa0000 8ffc0000 80082e18 80363274 00000000 90004400 efffffff 802b0008 802b9430 802b2000 00000000 0000001d 802b1f80 81291f30 00008000 00008000 7fffffff 00100100 00200200 7fffffff 80082958 afff62a8 00000000 00000001 8ffa0000 8ffc0000 8ffc0000 00000000 Call Trace: [<80080a30>] cobalt_irq+0x170/0x240 [<80082958>] cpu_idle+0x48/0x50 [<800ae97c>] irq_exit+0x5c/0x74 [<80082958>] cpu_idle+0x48/0x50 [<80081338>] ret_from_fork+0x0/0x8 [<80080470>] init+0x0/0x270 [<80082e18>] kernel_thread+0x74/0x8c [<80082958>] cpu_idle+0x48/0x50 [<80082958>] cpu_idle+0x48/0x50 [<80283dc0>] schedule+0x4c/0xacc [<80082958>] cpu_idle+0x48/0x50 [<8019e514>] idr_cache_ctor+0x0/0xc [<8032f764>] start_kernel+0x1b4/0x25c [<8032f0fc>] unknown_bootoption+0x0/0x310 Code: 8fb00010 03e00008 27bd0028 <0200000d> 080a1249 8f820010 27bdffb0 afbe0048 afb00040 >>$16; 0000000080082958 >>$18; 00000000802b2000 >>$25; 00000000802b1e23 >>$28; 00000000802b0000 >>$29; 00000000802b1e78 >>$30; 00000000802b1e78 >>$31; 0000000080081338 >>PC; 00000000802849b0 <===== Trace; 0000000080080a30 Trace; 0000000080082958 Trace; 00000000800ae97c Trace; 0000000080082958 Trace; 0000000080081338 Trace; 0000000080080470 Trace; 0000000080082e18 Trace; 0000000080082958 Trace; 0000000080082958 Trace; 0000000080283dc0 Trace; 0000000080082958 Trace; 000000008019e514 Trace; 000000008032f764 Trace; 000000008032f0fc Code; 00000000802849a4 00000000 <_PC>: Code; 00000000802849a4 0: 8fb00010 lw s0,16(sp) Code; 00000000802849a8 4: 03e00008 jr ra Code; 00000000802849ac 8: 27bd0028 addiu sp,sp,40 Code; 00000000802849b0 <===== c: 0200000d break 0x200 <===== Code; 00000000802849b4 10: 080a1249 j 284924 <_PC+0x284924> Code; 00000000802849b8 14: 8f820010 lw v0,16(gp) Code; 00000000802849bc 18: 27bdffb0 addiu sp,sp,-80 Code; 00000000802849c0 1c: afbe0048 sw s8,72(sp) Code; 00000000802849c4 20: afb00040 sw s0,64(sp) Kernel panic - not syncing: Attempted to kill the idle task! -- ---- Jim Gifford maillist@jg555.com From drow@nevyn.them.org Mon Mar 21 20:34:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 20:34:54 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:12501 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 20:34:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DDTbp-0001qb-3N; Mon, 21 Mar 2005 15:34:45 -0500 Date: Mon, 21 Mar 2005 15:34:45 -0500 From: Daniel Jacobowitz To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: NPTL support for the kernel Message-ID: <20050321203445.GA7082@nevyn.them.org> References: <20050316141151.GA23225@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316141151.GA23225@nevyn.them.org> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 836 Lines: 20 On Wed, Mar 16, 2005 at 09:11:52AM -0500, Daniel Jacobowitz wrote: > Here's a kernel patch to enable NPTL support. This doesn't include Maciej's > uber-fast rdhwr emulation; I believe we ought to include both the fast and > slow paths, since the slow path will handle use of other destination > registers. Changes: > > - Clone takes five arguments, not four. Um, this bit is gross. > - New syscall sys_set_thread_area. Only glibc uses this. > - Emulation of the rdhwr instruction. This version is only loosely > based on the emulation on the malta branch; the major difference > is that I fixed ll/sc/rdhwr emulation in branch delay slots. > GCC 4.1 will generate rdhwr in branch delay slots in some > conditions. > - PTRACE_GET_THREAD_AREA support for GDB. Ping? -- Daniel Jacobowitz CodeSourcery, LLC From eckhardt@satorlaser.com Mon Mar 21 20:53:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 20:53:20 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.189]:11499 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 20:53:05 +0000 Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDTtZ-0004Kq-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 21:53:05 +0100 Received: from [80.171.18.61] (helo=d018061.adsl.hansenet.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDTtY-00014f-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 21:53:04 +0100 From: Ulrich Eckhardt To: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Date: Mon, 21 Mar 2005 21:51:21 +0100 User-Agent: KMail/1.7.1 References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050320224028.GB6727@linux-mips.org> <423DFE7C.7040406@embeddedalley.com> In-Reply-To: <423DFE7C.7040406@embeddedalley.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200503212151.22059.eckhardt@satorlaser.com> Organization: Sator Laser GmbH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 581 Lines: 13 On Sunday 20 March 2005 23:51, Pete Popov wrote: > It works and no one has complained about any bugs. I hereby do complain that it doesn't work. ;) I'd give more details, but I'm neither at work nor did I investigate the situation properly. What I remember trying is to add 'console=/dev/ttyS0' or somesuch to the commandline, but couldn't get it to work there. The funny thing is that when I use the GDB support over serial line (which seems to use a primitive, stripped-down version of a serial driver) it works, I can then redirect boot messages via 'console=gdb'. Uli From ppopov@embeddedalley.com Mon Mar 21 20:57:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 20:57:28 +0000 (GMT) Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:3988 "HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Mon, 21 Mar 2005 20:57:13 +0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 21 Mar 2005 20:57:11 -0000 Message-ID: <423F3528.4060907@embeddedalley.com> Date: Mon, 21 Mar 2005 12:57:12 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050320224028.GB6727@linux-mips.org> <423DFE7C.7040406@embeddedalley.com> <200503212151.22059.eckhardt@satorlaser.com> In-Reply-To: <200503212151.22059.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 721 Lines: 25 Ulrich Eckhardt wrote: > On Sunday 20 March 2005 23:51, Pete Popov wrote: > >>It works and no one has complained about any bugs. > > > I hereby do complain that it doesn't work. ;) > > I'd give more details, but I'm neither at work nor did I investigate the > situation properly. What I remember trying is to add 'console=/dev/ttyS0' or > somesuch to the commandline, but couldn't get it to work there. Well, come on, I know that much works :) Which board and kernel rev? Pete > The funny > thing is that when I use the GDB support over serial line (which seems to use > a primitive, stripped-down version of a serial driver) it works, I can then > redirect boot messages via 'console=gdb'. > > Uli > > From joseph@omnilux.net Mon Mar 21 21:10:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 21:10:39 +0000 (GMT) Received: from foothill.iad.idealab.com ([IPv6:::ffff:64.208.8.35]:46345 "EHLO foothill.iad.idealab.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 21 Mar 2005 21:10:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Bitrotting serial drivers Date: Mon, 21 Mar 2005 13:10:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bitrotting serial drivers Thread-Index: AcUuWBr1A7Hs3VGhRa+RX9TP/rZGCwAAoKQQ From: "Joseph Chiu" To: "Ulrich Eckhardt" , Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joseph@omnilux.net Precedence: bulk X-list: linux-mips Content-Length: 1008 Lines: 30 Hmmm, that's news to me! I've been using console=ttyS0,115200 console=ttyS0,9600 and console= (no console) forever. > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ulrich Eckhardt > Sent: Monday, March 21, 2005 12:51 PM > To: linux-mips@linux-mips.org > Subject: Re: Bitrotting serial drivers > > > On Sunday 20 March 2005 23:51, Pete Popov wrote: > > It works and no one has complained about any bugs. > > I hereby do complain that it doesn't work. ;) > > I'd give more details, but I'm neither at work nor did I > investigate the > situation properly. What I remember trying is to add > 'console=/dev/ttyS0' or > somesuch to the commandline, but couldn't get it to work > there. The funny > thing is that when I use the GDB support over serial line > (which seems to use > a primitive, stripped-down version of a serial driver) it > works, I can then > redirect boot messages via 'console=gdb'. > > Uli > > From eckhardt@satorlaser.com Mon Mar 21 22:09:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Mar 2005 22:09:21 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.188]:3289 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Mon, 21 Mar 2005 22:09:03 +0000 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDV52-00033q-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 23:09:00 +0100 Received: from [80.171.18.61] (helo=d018061.adsl.hansenet.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDV52-0001td-00 for linux-mips@linux-mips.org; Mon, 21 Mar 2005 23:09:00 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers Date: Mon, 21 Mar 2005 23:07:18 +0100 User-Agent: KMail/1.7.1 References: <20050319172101.C23907@flint.arm.linux.org.uk> <200503212151.22059.eckhardt@satorlaser.com> <423F3528.4060907@embeddedalley.com> In-Reply-To: <423F3528.4060907@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503212307.18304.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 617 Lines: 15 On Monday 21 March 2005 21:57, Pete Popov wrote: > Ulrich Eckhardt wrote: > > I'd give more details, but I'm neither at work nor did I investigate the > > situation properly. What I remember trying is to add 'console=/dev/ttyS0' > > or somesuch to the commandline, but couldn't get it to work there. > > Well, come on, I know that much works :) Which board and kernel rev? > DB1100 derivative running 2.6.something from linux-mips CVS. Maybe it's just PEBKAC though, I can't rule that out. Maybe I'll get to trying tomorrow again, but it's not on the top of my priorities - that's rooting from CF currently. Uli From anemo@mba.ocn.ne.jp Tue Mar 22 00:40:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 00:41:14 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:57860 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Tue, 22 Mar 2005 00:40:59 +0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 22 Mar 2005 00:40:58 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 581E91EF7D; Tue, 22 Mar 2005 09:40:54 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 4443A18E4E; Tue, 22 Mar 2005 09:40:54 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j2M0er9c068761; Tue, 22 Mar 2005 09:40:53 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Tue, 22 Mar 2005 09:40:53 +0900 (JST) Message-Id: <20050322.094053.108307511.nemoto@toshiba-tops.co.jp> To: maillist@jg555.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: Current Build Warning Message From: Atsushi Nemoto In-Reply-To: <423F25AD.6030705@jg555.com> References: <423EF440.9090902@jg555.com> <423EF764.1070305@jg555.com> <423F25AD.6030705@jg555.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 397 Lines: 10 >>>>> On Mon, 21 Mar 2005 11:51:09 -0800, Jim Gifford said: Jim> Here are the warnings with ksym working. ... Jim> epc : 802849b0 preempt_schedule_irq+0xcc/0xd8 Not tainted Jim> ra : 80081338 ret_from_fork+0x0/0x8 Already fixed in CVS. http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-cvs-patches&i=aad20843b7b1d6b691c1401c495959a1%40NO-ID-FOUND.mhonarc.org From nunoe@co-nss.co.jp Tue Mar 22 00:47:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 00:47:55 +0000 (GMT) Received: from nssinet2.co-nss.co.jp ([IPv6:::ffff:150.96.0.5]:35320 "EHLO nssinet2.co-nss.co.jp") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 00:47:41 +0000 Received: from nssinet2.co-nss.co.jp (localhost [127.0.0.1]) by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id JAA01608 for ; Tue, 22 Mar 2005 09:41:07 +0900 (JST) Received: from nssnet.co-nss.co.jp (nssnet.co-nss.co.jp [150.96.64.250]) by nssinet2.co-nss.co.jp (8.9.3/3.7W) with ESMTP id JAA01604 for ; Tue, 22 Mar 2005 09:41:07 +0900 (JST) Received: from NUNOE ([150.96.160.60]) by nssnet.co-nss.co.jp (8.9.3+Sun/3.7W) with SMTP id JAA04644 for ; Tue, 22 Mar 2005 09:33:09 +0900 (JST) Message-ID: <006501c52e78$bb081730$3ca06096@NUNOE> From: "Hdei Nunoe" To: Subject: PSCHED_JSCALE Date: Tue, 22 Mar 2005 09:47:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nunoe@co-nss.co.jp Precedence: bulk X-list: linux-mips Content-Length: 947 Lines: 37 Hi there, Has anyone known about the background information about the following change? The PSCHED_JSCALE in the net/sched/sch_api.c is defined in the $B!!(Binclude/net/pkt_sched.h. If I set HZ to 1000 - PSCHED_JSCALE is 0 - what would happen? $B!!(B#if HZ == 100 $B!!(B#define PSCHED_JSCALE 13 $B!!(B#elif HZ == 1024 $B!!(B#define PSCHED_JSCALE 10 $B!!(B#else $B!!(B#define PSCHED_JSCALE 0 $B!!(B#endif $B!!(B $B!!(BThe code is updated in 2.4.27 as follows. The PSCHED_JSCALE becomes 10 in this case. What problems would it fix? Or what behaivior would change? $B!!(B#if HZ < 96 $B!!(B#define PSCHED_JSCALE 14 $B!!(B#elif HZ >= 96 && HZ < 192 $B!!(B#define PSCHED_JSCALE 13 $B!!(B#elif HZ >= 192 && HZ < 384 $B!!(B#define PSCHED_JSCALE 12 $B!!(B#elif HZ >= 384 && HZ < 768 $B!!(B#define PSCHED_JSCALE 11 $B!!(B#elif HZ >= 768 $B!!(B#define PSCHED_JSCALE 10 $B!!(B#endif --- Hdei Nunoe From kumba@gentoo.org Tue Mar 22 01:20:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 01:21:04 +0000 (GMT) Received: from rwcrmhc14.comcast.net ([IPv6:::ffff:216.148.227.89]:61863 "EHLO rwcrmhc14.comcast.net") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 01:20:50 +0000 Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45]) by comcast.net (rwcrmhc14) with ESMTP id <20050322012043014001ivice>; Tue, 22 Mar 2005 01:20:43 +0000 Message-ID: <423F7305.2030908@gentoo.org> Date: Mon, 21 Mar 2005 20:21:09 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: NPTL support for the kernel References: <20050316141151.GA23225@nevyn.them.org> <20050321203445.GA7082@nevyn.them.org> In-Reply-To: <20050321203445.GA7082@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 319 Lines: 15 Daniel Jacobowitz wrote: > > Ping? > Doesn't this need the glibc side of things to be effective?, or is it testable w/o that component? --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From ddaney@avtrex.com Tue Mar 22 01:41:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 01:42:12 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:17607 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 01:41:58 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Mar 2005 17:41:54 -0800 Message-ID: <423F77DF.2060808@avtrex.com> Date: Mon, 21 Mar 2005 17:41:51 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kumba CC: linux-mips@linux-mips.org Subject: Re: NPTL support for the kernel References: <20050316141151.GA23225@nevyn.them.org> <20050321203445.GA7082@nevyn.them.org> <423F7305.2030908@gentoo.org> In-Reply-To: <423F7305.2030908@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2005 01:41:54.0184 (UTC) FILETIME=[5384F080:01C52E80] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Content-Length: 484 Lines: 19 Kumba wrote: > Daniel Jacobowitz wrote: > >> >> Ping? >> > > Doesn't this need the glibc side of things to be effective?, or is it > testable w/o that component? I think the main point is that it should not break existing code. We need NPTL support in all three of GCC, Linux kernel and glibc before it can be tested. If it doesn't break existing code, I think it should go in the kernel so that we have something on which to test gcc and glibc. Just my $0.02 David Daney. From drow@nevyn.them.org Tue Mar 22 03:21:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 03:22:12 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:8360 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 03:21:56 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DDZxu-0006Iy-38; Mon, 21 Mar 2005 22:21:58 -0500 Date: Mon, 21 Mar 2005 22:21:58 -0500 From: Daniel Jacobowitz To: David Daney Cc: Kumba , linux-mips@linux-mips.org Subject: Re: NPTL support for the kernel Message-ID: <20050322032158.GA24188@nevyn.them.org> References: <20050316141151.GA23225@nevyn.them.org> <20050321203445.GA7082@nevyn.them.org> <423F7305.2030908@gentoo.org> <423F77DF.2060808@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423F77DF.2060808@avtrex.com> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 1009 Lines: 30 On Mon, Mar 21, 2005 at 05:41:51PM -0800, David Daney wrote: > Kumba wrote: > >Daniel Jacobowitz wrote: > > > >> > >>Ping? > >> > > > >Doesn't this need the glibc side of things to be effective?, or is it > >testable w/o that component? It is testable independently. Also, I posted the glibc bits last week. > I think the main point is that it should not break existing code. Of course. It doesn't. The only thing it could possibly break would be four-argument clone (it's supposed to be five argument, and the missing argument conventionally goes in the middle... oops). But I strongly believe nothing is yet using the four-argument form so I synced MIPS with the rest of the world. > We need NPTL support in all three of GCC, Linux kernel and glibc before > it can be tested. If it doesn't break existing code, I think it should > go in the kernel so that we have something on which to test gcc and glibc. GCC support was committed two weeks ago, BTW. -- Daniel Jacobowitz CodeSourcery, LLC From michael@cubic.org Tue Mar 22 08:01:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 08:01:37 +0000 (GMT) Received: from d062149.adsl.hansenet.de ([IPv6:::ffff:80.171.62.149]:16901 "EHLO gruft.cubic.org") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 08:01:21 +0000 Received: from cubic.org (starbase [192.168.10.1]) by gruft.cubic.org (8.12.2/8.12.2) with ESMTP id j2M81Hm9030651 for ; Tue, 22 Mar 2005 09:01:18 +0100 Message-ID: <423FC900.4010108@cubic.org> Date: Tue, 22 Mar 2005 08:28:00 +0100 From: Michael Stickel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Bitrotting serial drivers References: <20050319172101.C23907@flint.arm.linux.org.uk> <200503212151.22059.eckhardt@satorlaser.com> <423F3528.4060907@embeddedalley.com> <200503212307.18304.eckhardt@satorlaser.com> In-Reply-To: <200503212307.18304.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michael@cubic.org Precedence: bulk X-list: linux-mips Content-Length: 450 Lines: 17 Ulrich Eckhardt wrote: >On Monday 21 March 2005 21:57, Pete Popov wrote: > > >>Ulrich Eckhardt wrote: >> >> >>>I'd give more details, but I'm neither at work nor did I investigate the >>>situation properly. What I remember trying is to add 'console=/dev/ttyS0' >>>or somesuch to the commandline, but couldn't get it to work there. >>> Did you try console=ttyS0,* I also had some problems with the 2.6 release and the serial console. Michael From michael.stickel@4g-systems.biz Tue Mar 22 09:58:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 09:59:09 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:51417 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 09:58:52 +0000 Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDg9l-000055-00; Tue, 22 Mar 2005 10:58:37 +0100 Received: from [217.91.102.65] (helo=create.4g) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDg9l-0006CZ-00; Tue, 22 Mar 2005 10:58:37 +0100 From: Michael Stickel To: ppopov@embeddedalley.com Subject: Re: Bitrotting serial drivers Date: Tue, 22 Mar 2005 10:58:35 +0100 User-Agent: KMail/1.7 Cc: Ralf Baechle , Andrew Morton , Russell King , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org References: <20050319172101.C23907@flint.arm.linux.org.uk> <20050320224028.GB6727@linux-mips.org> <423DFE7C.7040406@embeddedalley.com> In-Reply-To: <423DFE7C.7040406@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503221058.35903.michael.stickel@4g-systems.biz> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f72049c8971f462876d14eb8b3ccbbf1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michael.stickel@4g-systems.biz Precedence: bulk X-list: linux-mips Content-Length: 1634 Lines: 29 If we leave the driver for the au1x00 as it is it should not have the register_serial / unregister_serial functions and it should be renamed to something else, e.g. ttySAxxx like it is done for the internal serial port of the strongarm (sa1100). I have thought about the serial driver and came along this. I we take a look at the hardware, we have a chip, the 8250 and its successors and the chip is integrated into some kind of hardware. So the chip has an interface. It has some address lines for register access, it has data lines and some controll lines. It also has an interrupt pin, some (GP)IO-Pins, that are freely programmable and a clock input. The chip is integrated thru some interface as I mentioned before. It can be an ISA-IO card or a PCI card or a multiport card, where more than one chip is accessed thru the same io-range and the hip to access is selected thru a single register. The au1x00 serial driver is like an ISA card except that the chip is mapped to a memory region instead of an io-region and the fact, that we can calculate the baud_base using the pll configuration of the au1x00, if we assume a 12MHz oscilator, which is standard for the au1x00. We need some access methods to access the chip registers, some way to handle intterupts, some way to deal with the gpio-pins, and we need a way to get the clock input of the chip. What should the serial-chip driver know about and what should the card driver know about. It's like the streams concept, where the chip driver does not know how to access the chip or what resources it uses, but what to do with the chip. Regards, Michael From eckhardt@satorlaser.com Tue Mar 22 13:04:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 13:04:51 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.191]:44782 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 13:04:34 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDj3h-00040K-00; Tue, 22 Mar 2005 14:04:33 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDj3g-0005gW-00; Tue, 22 Mar 2005 14:04:32 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] repair failed merges of 2.6.12 in au1000_eth.c Date: Tue, 22 Mar 2005 14:04:39 +0100 User-Agent: KMail/1.7.1 Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503221404.40050.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 3379 Lines: 120 Hi! Seems a few things went wrong merging 2.6.12 into the l-m.o CVS, leading to code duplication. The compiler complains about an unbalanced #ifdef. Uli Changes: * repair wrong merges of changes from 2.6.12 * remove an unused variable an an unnecessary set of brackets --- Index: drivers/net/au1000_eth.c =================================================================== RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v retrieving revision 1.43 diff -u -w -r1.43 au1000_eth.c --- drivers/net/au1000_eth.c 18 Mar 2005 17:37:32 -0000 1.43 +++ drivers/net/au1000_eth.c 22 Mar 2005 11:56:10 -0000 @@ -990,67 +990,7 @@ the stub will be found as well as the actual PHY. However, the last found PHY will be used... usually at Addr 31 (Db1500). */ - if ( (!phy_found) ) - { - u16 phy_id0, phy_id1; - int i; - - phy_id0 = 0x1234; - phy_id1 = 0x5678; - - /* search our mii table for the current mii */ - for (i = 0; mii_chip_table[i].phy_id1; i++) { - if (phy_id0 == mii_chip_table[i].phy_id0 && - phy_id1 == mii_chip_table[i].phy_id1) { - struct mii_phy * mii_phy = aup->mii; - - printk(KERN_INFO "%s: %s at phy address %d\n", - dev->name, mii_chip_table[i].name, - phy_addr); -#ifdef CONFIG_MIPS_BOSPORUS - phy_found = 1; -#endif - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - aup->want_autoneg = 1; - aup->phy_ops = mii_chip_table[i].phy_ops; - aup->phy_ops->phy_init(dev,phy_addr); - - // Check for dual-phy and then store required - // values and set indicators. We need to do - // this now since mdio_{read,write} need the - // control and data register addresses. - #ifdef CONFIG_BCM5222_DUAL_PHY - if ( mii_chip_table[i].dual_phy) { - - /* assume both phys are controlled - * through MAC0. Board specific? */ - - /* sanity check */ - if (!au_macs[0] || !au_macs[0]->mii) - return -1; - aup->mii->mii_control_reg = (u32 *) - &au_macs[0]->mac->mii_control; - aup->mii->mii_data_reg = (u32 *) - &au_macs[0]->mac->mii_data; - } - #endif - goto found; - } - } - } -found: - -#ifdef CONFIG_MIPS_BOSPORUS - /* This is a workaround for the Micrel/Kendin 5 port switch - The second MAC doesn't see a PHY connected... so we need to - trick it into thinking we have one. - - If this kernel is run on another Au1500 development board - the stub will be found as well as the actual PHY. However, - the last found PHY will be used... usually at Addr 31 (Db1500). - */ - if ( (!phy_found) ) + if ( !phy_found) { u16 phy_id0, phy_id1; int i; @@ -1841,7 +1781,6 @@ static int au1000_close(struct net_device *dev) { - int i; u32 flags; struct au1000_private *aup = (struct au1000_private *) dev->priv; @@ -2159,23 +2098,6 @@ return crc; } - -static unsigned const ethernet_polynomial = 0x04c11db7U; -static inline u32 ether_crc(int length, unsigned char *data) -{ - int crc = -1; - - while(--length >= 0) { - unsigned char current_octet = *data++; - int bit; - for (bit = 0; bit < 8; bit++, current_octet >>= 1) - crc = (crc << 1) ^ - ((crc < 0) ^ (current_octet & 1) ? - ethernet_polynomial : 0); - } - return crc; -} - static void set_rx_mode(struct net_device *dev) { struct au1000_private *aup = (struct au1000_private *) dev->priv; From eckhardt@satorlaser.com Tue Mar 22 14:31:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 14:31:56 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.190]:9200 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 14:31:41 +0000 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDkPz-0001Oz-00 for linux-mips@linux-mips.org; Tue, 22 Mar 2005 15:31:39 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDkPy-0000CM-00 for linux-mips@linux-mips.org; Tue, 22 Mar 2005 15:31:38 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Off by two error in au1000/common/setup.c? Date: Tue, 22 Mar 2005 15:31:46 +0100 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503221531.46186.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 660 Lines: 23 Hi! Could someone take a look at these lines from fixup_bigphys_addr(): // in au1000.h #define Au1500_PCI_MEM_START 0x440000000ULL #define Au1500_PCI_MEM_END 0x44FFFFFFFULL // in setup.c start = (u32)Au1500_PCI_MEM_START; end = (u32)Au1500_PCI_MEM_END; /* check for pci memory window */ if ((phys_addr >= start) && ((phys_addr + size) < end)) { return (phys_addr - start) + Au1500_PCI_MEM_START; } For the (unlikely?) case that I want to use a size of 0x0 1000 0000, 'phys_addr+size == end+1'. IOW I need 'phys_addr+size-1' to get the last address and use '<= end' to compare with the last valid address in the range. Right? Uli From eckhardt@satorlaser.com Tue Mar 22 15:38:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 15:38:56 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.185]:8919 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 15:38:41 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DDlSp-0003G5-00 for linux-mips@linux-mips.org; Tue, 22 Mar 2005 16:38:39 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DDlSp-0001aD-00 for linux-mips@linux-mips.org; Tue, 22 Mar 2005 16:38:39 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: ohci-au1xxx.c breakage Date: Tue, 22 Mar 2005 16:38:46 +0100 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503221638.46922.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 328 Lines: 10 Greetings! There seem to have been some changes to the USB driver kernel API which the Au1xxx driver wasn't adapted to. I just wanted to say that I'm working on it, but without really knowing much about the framework so success is not guaranteed... If someone else wants to earn the fame I will happily step back. ;) Uli From ppopov@embeddedalley.com Tue Mar 22 16:44:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 16:44:58 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com ([IPv6:::ffff:216.136.130.195]:25515 "HELO smtp003.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Tue, 22 Mar 2005 16:44:42 +0000 Received: from unknown (HELO ?127.0.0.1?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp003.bizmail.yahoo.com with SMTP; 22 Mar 2005 16:44:38 -0000 Message-ID: <42404B78.6090008@embeddedalley.com> Date: Tue, 22 Mar 2005 08:44:40 -0800 From: Pete Popov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: ohci-au1xxx.c breakage References: <200503221638.46922.eckhardt@satorlaser.com> In-Reply-To: <200503221638.46922.eckhardt@satorlaser.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 508 Lines: 18 Ulrich Eckhardt wrote: >Greetings! > >There seem to have been some changes to the USB driver kernel API which the >Au1xxx driver wasn't adapted to. I just wanted to say that I'm working on it, >but without really knowing much about the framework so success is not >guaranteed... > >If someone else wants to earn the fame I will happily step back. ;) > > I assume you're talking about 2.6? If you can fix it correctly, go for it and send the patch. Otherwise we'll have to fix it, again, soon. Pete From gilad@romat.com Tue Mar 22 16:56:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 16:56:33 +0000 (GMT) Received: from mxout4.netvision.net.il ([IPv6:::ffff:194.90.9.27]:33920 "EHLO mxout4.netvision.net.il") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 16:56:18 +0000 Received: from [192.168.1.199] ([212.143.245.6]) by mxout4.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Dec 14 2004)) with ESMTP id <0IDR00M2OJ1ISO70@mxout4.netvision.net.il> for linux-mips@linux-mips.org; Tue, 22 Mar 2005 18:56:07 +0200 (IST) Date: Tue, 22 Mar 2005 18:56:14 +0200 From: Gilad Rom Subject: Gigabit Ethernet To: "'linux-mips@linux-mips.org'" Message-id: <42404E2E.1030207@romat.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gilad@romat.com Precedence: bulk X-list: linux-mips Content-Length: 123 Lines: 7 Hello List, Has anyone ever tried using a Gigabit PCI adapter with one of the Au1x00 boards? Any success? Thanks, Gilad. From ppopov@embeddedalley.com Tue Mar 22 17:46:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 17:46:29 +0000 (GMT) Received: from smtp006.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.83]:41149 "HELO smtp006.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Tue, 22 Mar 2005 17:46:13 +0000 Received: from unknown (HELO ?127.0.0.1?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp006.bizmail.sc5.yahoo.com with SMTP; 22 Mar 2005 17:46:08 -0000 Message-ID: <424059E2.201@embeddedalley.com> Date: Tue, 22 Mar 2005 09:46:10 -0800 From: Pete Popov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: Off by two error in au1000/common/setup.c? References: <200503221531.46186.eckhardt@satorlaser.com> In-Reply-To: <200503221531.46186.eckhardt@satorlaser.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 877 Lines: 31 Ulrich Eckhardt wrote: >Hi! > >Could someone take a look at these lines from fixup_bigphys_addr(): > > // in au1000.h > #define Au1500_PCI_MEM_START 0x440000000ULL > #define Au1500_PCI_MEM_END 0x44FFFFFFFULL > > // in setup.c > start = (u32)Au1500_PCI_MEM_START; > end = (u32)Au1500_PCI_MEM_END; > /* check for pci memory window */ > if ((phys_addr >= start) && ((phys_addr + size) < end)) { > return (phys_addr - start) + Au1500_PCI_MEM_START; > } > >For the (unlikely?) case that I want to use a size of 0x0 1000 0000, >'phys_addr+size == end+1'. IOW I need 'phys_addr+size-1' to get the last >address and use '<= end' to compare with the last valid address in the range. > >Right? > > But the a size of 0x0 1000 0001 would pass the test since phys_addr + 1000 0001 - 1 <= end. How about if I just make MEM_END 0x450000000 and the check " <= end" ? Pete From gilad@romat.com Tue Mar 22 18:42:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 18:42:23 +0000 (GMT) Received: from mxout4.netvision.net.il ([IPv6:::ffff:194.90.9.27]:10965 "EHLO mxout4.netvision.net.il") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 18:42:08 +0000 Received: from [192.168.1.199] ([212.143.245.6]) by mxout4.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Dec 14 2004)) with ESMTP id <0IDR00MKVNY2VB70@mxout4.netvision.net.il> for linux-mips@linux-mips.org; Tue, 22 Mar 2005 20:42:02 +0200 (IST) Date: Tue, 22 Mar 2005 20:42:14 +0200 From: Gilad Rom Subject: Au1500 and 1Gbps To: "'linux-mips@linux-mips.org'" Message-id: <42406706.90409@romat.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gilad@romat.com Precedence: bulk X-list: linux-mips Content-Length: 508 Lines: 16 Hello, As a follow up to my last posting, I was wondering if anyone ever actually benchmarked the Au1500 in terms of networking throughput. We make a custom board, based on the Au1500. 100Mbps performance is 100% (100Mbps FTP transfers when using brctl to bridge both ethernet MAC's), but What we would like to do, ultimately, is build a board with two Gigabit MAC/PHY's and use our board to construct a much more powerful gateway. Any insight? can the Au1500 even try to handle 1000Mbps? Thanks, Gilad. From ppopov@embeddedalley.com Tue Mar 22 18:47:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 18:47:17 +0000 (GMT) Received: from smtp006.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.83]:31358 "HELO smtp006.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Tue, 22 Mar 2005 18:47:02 +0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp006.bizmail.sc5.yahoo.com with SMTP; 22 Mar 2005 18:47:00 -0000 Message-ID: <42406826.2040302@embeddedalley.com> Date: Tue, 22 Mar 2005 10:47:02 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gilad Rom CC: "'linux-mips@linux-mips.org'" Subject: Re: Au1500 and 1Gbps References: <42406706.90409@romat.com> In-Reply-To: <42406706.90409@romat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 694 Lines: 19 Gilad Rom wrote: > Hello, > > As a follow up to my last posting, I was wondering if anyone > ever actually benchmarked the Au1500 in terms of networking > throughput. > > We make a custom board, based on the Au1500. 100Mbps > performance is 100% (100Mbps FTP transfers when using brctl to bridge > both ethernet MAC's), but What we would like to do, ultimately, > is build a board with two Gigabit MAC/PHY's and use our board > to construct a much more powerful gateway. > > Any insight? can the Au1500 even try to handle 1000Mbps? Should be easy to get up and running the benchmarked. The Intel 1G driver (e100?) should run fine on mips with, hopefully, little or no modifications. Pete From gilad@romat.com Tue Mar 22 18:51:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 18:51:51 +0000 (GMT) Received: from mxout1.netvision.net.il ([IPv6:::ffff:194.90.9.20]:40778 "EHLO mxout1.netvision.net.il") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 18:51:36 +0000 Received: from [192.168.1.199] ([212.143.245.6]) by mxout1.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Dec 14 2004)) with ESMTP id <0IDR008Z2ODUYAH0@mxout1.netvision.net.il> for linux-mips@linux-mips.org; Tue, 22 Mar 2005 20:51:30 +0200 (IST) Date: Tue, 22 Mar 2005 20:51:42 +0200 From: Gilad Rom Subject: Re: Au1500 and 1Gbps In-reply-to: <42406826.2040302@embeddedalley.com> To: ppopov@embeddedalley.com Cc: "'linux-mips@linux-mips.org'" Message-id: <4240693E.3060207@romat.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <42406706.90409@romat.com> <42406826.2040302@embeddedalley.com> User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gilad@romat.com Precedence: bulk X-list: linux-mips Content-Length: 366 Lines: 14 >> >> Any insight? can the Au1500 even try to handle 1000Mbps? > > > Should be easy to get up and running the benchmarked. The Intel 1G > driver (e100?) should run fine on mips with, hopefully, little or no > modifications. > > Pete Do you see any theoretical limitation on the Au1500 which would prevent it from utilizing the full 1000Mbps bandwidth? Gilad. From ppopov@embeddedalley.com Tue Mar 22 18:55:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 18:55:56 +0000 (GMT) Received: from smtp008.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.74]:37537 "HELO smtp008.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Tue, 22 Mar 2005 18:55:41 +0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp008.bizmail.sc5.yahoo.com with SMTP; 22 Mar 2005 18:55:39 -0000 Message-ID: <42406A2D.6020905@embeddedalley.com> Date: Tue, 22 Mar 2005 10:55:41 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gilad Rom CC: "'linux-mips@linux-mips.org'" Subject: Re: Au1500 and 1Gbps References: <42406706.90409@romat.com> <42406826.2040302@embeddedalley.com> <4240693E.3060207@romat.com> In-Reply-To: <4240693E.3060207@romat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 684 Lines: 22 Gilad Rom wrote: >>> >>> Any insight? can the Au1500 even try to handle 1000Mbps? >> >> >> >> Should be easy to get up and running the benchmarked. The Intel 1G >> driver (e100?) should run fine on mips with, hopefully, little or no >> modifications. >> >> Pete > > > Do you see any theoretical limitation on the Au1500 which > would prevent it from utilizing the full 1000Mbps bandwidth? I haven't done any paper napkin calculations on what it takes to handle the smallest packets, worst case, at 1G. It also depends on what else your CPU is doing. If you're just routing packets you'll get a lot better performance then you would if you're busy doing something else. Pete From dan@embeddededge.com Tue Mar 22 21:04:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Mar 2005 21:04:19 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:45578 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Tue, 22 Mar 2005 21:04:04 +0000 Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j2ML2FPt013344; Tue, 22 Mar 2005 16:02:15 -0500 In-Reply-To: <42404E2E.1030207@romat.com> References: <42404E2E.1030207@romat.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <62642b91fa50ac5f881ed8fa9400deed@embeddededge.com> Content-Transfer-Encoding: 7bit Cc: "'linux-mips@linux-mips.org'" From: Dan Malek Subject: Re: Gigabit Ethernet Date: Tue, 22 Mar 2005 16:04:13 -0500 To: Gilad Rom X-Mailer: Apple Mail (2.619.2) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@embeddededge.com Precedence: bulk X-list: linux-mips Content-Length: 471 Lines: 17 On Mar 22, 2005, at 11:56 AM, Gilad Rom wrote: > Has anyone ever tried using a Gigabit PCI > adapter with one of the Au1x00 boards? Any success? Just remember that the Au1x00 boards are 32-bit , 33 MHz, 3.3V PCI, so choose your boards accordingly. Please don't expect the Au1x00 to run the TCP/IP stack anywhere near Gigabit speeds ..... :-) Read the networking mailing lists for the actual performance of various systems at these network speeds. Thanks. -- Dan From joeg@clearcore.com Wed Mar 23 00:12:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 00:12:23 +0000 (GMT) Received: from www.clearcore.com ([IPv6:::ffff:69.20.152.109]:3747 "EHLO sam.clearcore.com") by linux-mips.org with ESMTP id ; Wed, 23 Mar 2005 00:12:08 +0000 Received: by sam.clearcore.com (Postfix, from userid 501) id 521027E68; Tue, 22 Mar 2005 17:12:05 -0700 (MST) From: joeg To: linux-mips@linux-mips.org, ppopov@embeddedalley.com, eckhardt@satorlaser.com Subject: Re: ohci-au1xxx.c breakage Message-Id: <20050323001205.521027E68@sam.clearcore.com> Date: Tue, 22 Mar 2005 17:12:05 -0700 (MST) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joeg@sam.clearcore.com Precedence: bulk X-list: linux-mips Content-Length: 3207 Lines: 129 This patch works for me on an Au1550 little endian. Joe --- linux-2.6.11-3/drivers/usb/host/ohci-au1xxx.c 2005-03-18 10:37:49.000000000 -0700 +++ test_2.6.11_3_tree/drivers/usb/host/ohci-au1xxx.c 2005-03-22 15:29:14.376513351 -0700 @@ -84,97 +84,48 @@ static void au1xxx_stop_hc(struct platfo * */ int usb_hcd_au1xxx_probe (const struct hc_driver *driver, - struct usb_hcd **hcd_out, struct platform_device *dev) { int retval; - struct usb_hcd *hcd = 0; - - unsigned int *addr = NULL; - - if (!request_mem_region(dev->resource[0].start, - dev->resource[0].end - - dev->resource[0].start + 1, hcd_name)) { - pr_debug("request_mem_region failed"); - return -EBUSY; - } - - au1xxx_start_hc(dev); - - addr = ioremap(dev->resource[0].start, - dev->resource[0].end - - dev->resource[0].start + 1); - if (!addr) { - pr_debug("ioremap failed"); - retval = -ENOMEM; - goto out_release; - } + struct usb_hcd *hcd; if (dev->resource[1].flags != IORESOURCE_IRQ) { pr_debug ("resource[1] is not IORESOURCE_IRQ"); retval = -ENOMEM; - goto out_iounmap; } - hcd = usb_create_hcd(driver); - if (hcd == NULL) { - pr_debug ("usb_create_hcd failed"); - retval = -ENOMEM; - goto out_iounmap; - } - ohci_hcd_init(hcd_to_ohci(hcd)); + hcd = usb_create_hcd(driver, &dev->dev, "Au1xxx"); + if (!hcd) + return -ENOMEM; + hcd->rsrc_start = dev->resource[0].start; + hcd->rsrc_len = dev->resource[0].end - dev->resource[0].start + 1; - hcd->irq = dev->resource[1].start; - hcd->regs = addr; - hcd->self.controller = &dev->dev; - - retval = hcd_buffer_create (hcd); - if (retval != 0) { - pr_debug ("pool alloc fail"); - goto out_put_hcd; - } - - retval = request_irq (hcd->irq, usb_hcd_au1xxx_hcim_irq, SA_INTERRUPT, - hcd->driver->description, hcd); - if (retval != 0) { - pr_debug("request_irq failed"); + if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) { + pr_debug("request_mem_region failed"); retval = -EBUSY; - goto out_free_buffer; + goto err1; } - pr_debug ("%s (Au1xxx) at 0x%p, irq %d", - hcd->driver->description, hcd->regs, hcd->irq); - - hcd->self.bus_name = "au1xxx"; - - if ((retval = usb_register_bus(&hcd->self))) - goto out_free_irq; - - if ((retval = driver->start(hcd)) < 0) { - usb_hcd_au1xxx_remove(hcd, dev); - printk("bad driver->start\n"); - return retval; + hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len); + if (!hcd->regs) { + pr_debug("ioremap failed"); + retval = -ENOMEM; + goto err2; } - *hcd_out = hcd; + au1xxx_start_hc(dev); + ohci_hcd_init(hcd_to_ohci(hcd)); - return 0; + retval = usb_add_hcd(hcd, dev->resource[1].start, SA_INTERRUPT); + if (retval == 0) + return retval; -out_unregister_bus: - usb_deregister_bus(&hcd->self); -out_free_irq: - free_irq(hcd->irq, hcd); -out_free_buffer: - hcd_buffer_destroy (hcd); -out_put_hcd: - usb_put_hcd(hcd); -out_iounmap: - iounmap(addr); -out_release: au1xxx_stop_hc(dev); - release_mem_region(dev->resource[0].start, - dev->resource[0].end - - dev->resource[0].start + 1); + iounmap(hcd->regs); + err2: + release_mem_region(hcd->rsrc_start, hcd->rsrc_len); + err1: + usb_put_hcd(hcd); return retval; } From eckhardt@satorlaser.com Wed Mar 23 07:36:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 07:36:48 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.177]:24803 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 23 Mar 2005 07:36:32 +0000 Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DE0Pc-00083y-00 for linux-mips@linux-mips.org; Wed, 23 Mar 2005 08:36:20 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DE0Pc-0006kA-00 for linux-mips@linux-mips.org; Wed, 23 Mar 2005 08:36:20 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: Off by two error in au1000/common/setup.c? Date: Wed, 23 Mar 2005 08:36:29 +0100 User-Agent: KMail/1.7.1 References: <200503221531.46186.eckhardt@satorlaser.com> <424059E2.201@embeddedalley.com> In-Reply-To: <424059E2.201@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503230836.29948.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 1309 Lines: 37 Pete Popov wrote: > > // in au1000.h > > #define Au1500_PCI_MEM_START 0x440000000ULL > > #define Au1500_PCI_MEM_END 0x44FFFFFFFULL > > > > // in setup.c > > start = (u32)Au1500_PCI_MEM_START; > > end = (u32)Au1500_PCI_MEM_END; > > /* check for pci memory window */ > > if ((phys_addr >= start) && ((phys_addr + size) < end)) { > > return (phys_addr - start) + Au1500_PCI_MEM_START; > > } > > > >For the (unlikely?) case that I want to use a size of 0x0 1000 0000, > >'phys_addr+size == end+1'. IOW I need 'phys_addr+size-1' to get the last > >address and use '<= end' to compare with the last valid address in the > > range. > > > >Right? > > But the a size of 0x0 1000 0001 would pass the test since phys_addr + > 1000 0001 - 1 <= end. Really? 0x4 4000 0000 + 0x0 1000 0001 - 1 = 0x4 5000 0000 > 0x4 ffff ffff ;) > How about if I just make MEM_END 0x450000000 and the check " <= end" ? I'm not sure, it's a question of consistency: that solution would be the one-past-the-end address, which I'm fine with (being used to C++'s STL-style iterators..). The only problem I see arises if that one-past-the-end actually wraps around. Other than that, what is used generally, first and last valid address or first valid address and first not valid address? Or first valid address and size? Uli From ppopov@embeddedalley.com Wed Mar 23 07:43:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 07:44:04 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com ([IPv6:::ffff:216.136.130.195]:55201 "HELO smtp003.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 23 Mar 2005 07:43:49 +0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp003.bizmail.yahoo.com with SMTP; 23 Mar 2005 07:43:45 -0000 Message-ID: <42411E34.2080606@embeddedalley.com> Date: Tue, 22 Mar 2005 23:43:48 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: Off by two error in au1000/common/setup.c? References: <200503221531.46186.eckhardt@satorlaser.com> <424059E2.201@embeddedalley.com> <200503230836.29948.eckhardt@satorlaser.com> In-Reply-To: <200503230836.29948.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1443 Lines: 45 Ulrich Eckhardt wrote: > Pete Popov wrote: > >>>// in au1000.h >>>#define Au1500_PCI_MEM_START 0x440000000ULL >>>#define Au1500_PCI_MEM_END 0x44FFFFFFFULL >>> >>>// in setup.c >>>start = (u32)Au1500_PCI_MEM_START; >>>end = (u32)Au1500_PCI_MEM_END; >>>/* check for pci memory window */ >>>if ((phys_addr >= start) && ((phys_addr + size) < end)) { >>> return (phys_addr - start) + Au1500_PCI_MEM_START; >>>} >>> >>>For the (unlikely?) case that I want to use a size of 0x0 1000 0000, >>>'phys_addr+size == end+1'. IOW I need 'phys_addr+size-1' to get the last >>>address and use '<= end' to compare with the last valid address in the >>>range. >>> >>>Right? >> >>But the a size of 0x0 1000 0001 would pass the test since phys_addr + >>1000 0001 - 1 <= end. > > > Really? > 0x4 4000 0000 + 0x0 1000 0001 - 1 = 0x4 5000 0000 > 0x4 ffff ffff > ;) Yeh, I was already thinking about end==0x4 5000 0000 ... >>How about if I just make MEM_END 0x450000000 and the check " <= end" ? > > > I'm not sure, it's a question of consistency: that solution would be the > one-past-the-end address, which I'm fine with (being used to C++'s STL-style > iterators..). The only problem I see arises if that one-past-the-end actually > wraps around. > Other than that, what is used generally, first and last valid address or first > valid address and first not valid address? Or first valid address and size? I'll check it out tomorrow. Pete From eckhardt@satorlaser.com Wed Mar 23 08:45:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 08:45:55 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.190]:50431 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 23 Mar 2005 08:45:32 +0000 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DE1UX-0000nq-00 for linux-mips@linux-mips.org; Wed, 23 Mar 2005 09:45:29 +0100 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DE1UX-00071N-00 for linux-mips@linux-mips.org; Wed, 23 Mar 2005 09:45:29 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: ohci-au1xxx.c breakage Date: Wed, 23 Mar 2005 09:45:38 +0100 User-Agent: KMail/1.7.1 References: <20050323001205.521027E68@sam.clearcore.com> In-Reply-To: <20050323001205.521027E68@sam.clearcore.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200503230945.39089.eckhardt@satorlaser.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 112 Lines: 8 joeg wrote: > This patch works for me on an Au1550 little endian. AOL, on a DB1100 derived board. thanks Uli From ddaniels@fortresstech.com Wed Mar 23 18:56:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 18:57:13 +0000 (GMT) Received: from 67-129-173-8.dia.cust.qwest.net ([IPv6:::ffff:67.129.173.8]:37913 "EHLO alfalfa.fortresstech.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Wed, 23 Mar 2005 18:56:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: defkeymap.c Compile Warnings . . . Date: Wed, 23 Mar 2005 13:56:50 -0500 Message-ID: <54AC63178735ED46BAC5F5E668A9F224046AAC@alfalfa.fortresstech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: defkeymap.c Compile Warnings . . . Thread-Index: AcUv2hGp4A8rhlYBSRyM+bTUV7W0Ig== From: "Dennis Daniels" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaniels@fortresstech.com Precedence: bulk X-list: linux-mips Content-Length: 4140 Lines: 62 I'm having a compile problem with the generated file defkeymap.c for Linux 64-bit MIPS on the BCM1250, and was wondering if anyone has seen or heard of it. The structures in defkeymap.c are all coming out 2x what they should be . . . Thanks ahead of time, Dennis Target:              BCM1250/64-bit Linux kernel:      2.4.20 gcc:                  3.3.1 The warnings I'm getting are: mips64_fp_be-gcc -D__KERNEL__ -I/ws/ddaniels/projects/ddaniels-01/Arch_2/Patriot/SQA/Main/Applications/thirdparty/kernel/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fnostrict-aliasing -fno-common -fomit-frame-pointer -I /ws /ddaniels/projects/ddaniels-01/Arch_2/Patriot/SQA/Main/Applications/thirdparty/kernel/linux/include/asm/gcc -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pip e -mtune=sb1 -mips64   -nostdinc -iwithprefix include -DKBUILD_BASENAME=defkeymap  -c -o defkeymap.o defkeymap.c defkeymap.c:25: warning: excess elements in array initializer defkeymap.c:25: warning: (near initialization for `plain_map') defkeymap.c:25: warning: excess elements in array initializer defkeymap.c:25: warning: (near initialization for `plain_map') : : defkeymap.c:250: warning: excess elements in array initializer defkeymap.c:250: warning: (near initialization for `ctrl_alt_map') defkeymap.c:250: warning: excess elements in array initializer defkeymap.c:250: warning: (near initialization for `ctrl_alt_map' and the structure looks like: u_short plain_map[NR_KEYS] = {             0xf200,  0xf01b,  0xf031,  0xf032,  0xf033,  0xf034,  0xf035,  0xf036,             0xf037,  0xf038,  0xf039,  0xf030,  0xf02d,  0xf03d,  0xf07f,   0xf009,             0xfb71,  0xfb77,  0xfb65,  0xfb72,  0xfb74,  0xfb79,  0xfb75,  0xfb69,             0xfb6f,  0xfb70,  0xf05b,  0xf05d,  0xf201,  0xf702,  0xfb61,  0xfb73,             0xfb64,  0xfb66,  0xfb67,  0xfb68,  0xfb6a,  0xfb6b,  0xfb6c,  0xf03b,             0xf027,  0xf060,  0xf700,  0xf05c,  0xfb7a,  0xfb78,  0xfb63,  0xfb76,             0xfb62,  0xfb6e,  0xfb6d,  0xf02c,  0xf02e,  0xf02f,  0xf700,  0xf30c,             0xf703,  0xf020,  0xf207,  0xf100,  0xf101,  0xf102,  0xf103,  0xf104,             0xf105,  0xf106,  0xf107,  0xf108,  0xf109,  0xf208,  0xf209,  0xf307,             0xf308,  0xf309,  0xf30b,  0xf304,  0xf305,  0xf306,  0xf30a,  0xf301,             0xf302,  0xf303,  0xf300,  0xf310,  0xf206,  0xf200,  0xf03c,  0xf10a,             0xf10b,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf30e,  0xf702,  0xf30d,  0xf01c,  0xf701,  0xf205,  0xf114,  0xf603,             0xf118,  0xf601,  0xf602,  0xf117,  0xf600,  0xf119,  0xf115,  0xf116,             0xf11a,  0xf10c,  0xf10d,  0xf11b,  0xf11c,  0xf110,  0xf311,  0xf11d,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,             0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200,  0xf200, };   From karsten@excalibur.cologne.de Wed Mar 23 19:14:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Mar 2005 19:14:17 +0000 (GMT) Received: from natnoddy.rzone.de ([IPv6:::ffff:81.169.145.166]:13018 "EHLO natnoddy.rzone.de") by linux-mips.org with ESMTP id ; Wed, 23 Mar 2005 19:14:02 +0000 Received: from excalibur.cologne.de (cable-195-14-198-241.netcologne.de [195.14.198.241]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j2NJE0i2028093 for ; Wed, 23 Mar 2005 20:14:01 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.36 #1 (Debian)) id 1DEBIn-0001b2-00 for ; Wed, 23 Mar 2005 20:14:01 +0100 Date: Wed, 23 Mar 2005 20:14:01 +0100 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: defkeymap.c Compile Warnings . . . Message-ID: <20050323191400.GA6038@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org References: <54AC63178735ED46BAC5F5E668A9F224046AAC@alfalfa.fortresstech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AC63178735ED46BAC5F5E668A9F224046AAC@alfalfa.fortresstech.com> X-No-Archive: yes User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips Content-Length: 984 Lines: 30 On Wed, Mar 23, 2005 at 01:56:50PM -0500, Dennis Daniels wrote: > I'm having a compile problem with the generated file defkeymap.c for Linux > 64-bit MIPS on the BCM1250, and was wondering if anyone has seen or heard > of it. The structures in defkeymap.c are all coming out 2x what they > should be . . . AFAICS the reason is a change in the kernel headers between 2.4 and 2.6. In 2.4, the file linux/keyboard.h has #define NR_KEYS 128 while in 2.6 it has #define NR_KEYS 256 The loadkeys command that is used to generate the defkeymap.c file has probably been built against 2.6 headers -> it generates arrays with 256 instead of 128 entries, which would lead to the "excess elements in array initializer" error you are experiencing. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From alex.gonzalez@packetvision.com Thu Mar 24 11:26:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Mar 2005 11:26:53 +0000 (GMT) Received: from smtp.uk.colt.net ([IPv6:::ffff:195.110.64.125]:53148 "EHLO smtp.uk.colt.net") by linux-mips.org with ESMTP id ; Thu, 24 Mar 2005 11:26:36 +0000 Received: from euskadi.packetvision (unknown [213.86.106.84]) by smtp.uk.colt.net (Postfix) with ESMTP id 7062D12EBC3; Thu, 24 Mar 2005 11:24:53 +0000 (GMT) Subject: ABI incompatibility when building util-linux From: Alex Gonzalez To: debian-mips@lists.debian.org Cc: linux-mips@linux-mips.org Content-Type: text/plain Message-Id: <1111663536.27220.32.camel@euskadi.packetvision> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Thu, 24 Mar 2005 11:25:36 +0000 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alex.gonzalez@packetvision.com Precedence: bulk X-list: linux-mips Content-Length: 13378 Lines: 151 Hi, When compiling the util-linux-2.12q sources, I get the following linker ABI incompatibility error: [alex@euskadi util-linux-2.12q]$ make make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/po' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/Projects/util-linux-2.12q/po' make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/lib' mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" err.c -o err.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" my_reboot.c -o my_reboot.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" setproctitle.c -o setproctitle.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" env.c -o env.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" carefulputc.c -o carefulputc.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" xstrncpy.c -o xstrncpy.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" md5.c -o md5.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done make[1]: Leaving directory `/home/alex/Projects/util-linux-2.12q/lib' make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/getopt' mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" getopt.c -o getopt.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-ld -V -static -t -EB getopt.o -o getopt GNU ld version 2.13-mips64linux-031001 20020920 Supported emulations: elf32btsmipn32 elf32ltsmipn32 elf32btsmip elf32ltsmip elf64btsmip elf64ltsmip mips64-linux-gnu-ld: mode elf32btsmipn32 getopt.o mips64-linux-gnu-ld: getopt.o: ABI is incompatible with that of the selected emulation File in wrong format: failed to merge target specific data of file getopt.o mips64-linux-gnu-ld: warning: cannot find entry symbol __start; defaulting to 00000000100000a0 getopt.o: In function `our_malloc': getopt.o(.text+0x18): undefined reference to `malloc' make[1]: *** [getopt] Segmentation fault make[1]: *** Deleting file `getopt' make[1]: Leaving directory `/home/alex/Projects/util-linux-2.12q/getopt' make: *** [all] Error 1 If I try with -melf32btsmip, I get the following error: [alex@euskadi util-linux-2.12q]$ make make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/po' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/Projects/util-linux-2.12q/po' make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/lib' mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" err.c -o err.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" my_reboot.c -o my_reboot.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" setproctitle.c -o setproctitle.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" env.c -o env.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" carefulputc.c -o carefulputc.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" xstrncpy.c -o xstrncpy.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" md5.c -o md5.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done make[1]: Leaving directory `/home/alex/Projects/util-linux-2.12q/lib' make[1]: Entering directory `/home/alex/Projects/util-linux-2.12q/getopt' mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -Wl,-melf32btsmip -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" getopt.c -o getopt.o mips64-linux-gnu-gcc: -t: linker input file unused because linking not done mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done mips64-linux-gnu-gcc: -melf32btsmip: linker input file unused because linking not done mips64-linux-gnu-ld -V -static -t -EB -melf32btsmip getopt.o -o getopt GNU ld version 2.13-mips64linux-031001 20020920 Supported emulations: elf32btsmipn32 elf32ltsmipn32 elf32btsmip elf32ltsmip elf64btsmip elf64ltsmip mips64-linux-gnu-ld: mode elf32btsmip getopt.o mips64-linux-gnu-ld: warning: cannot find entry symbol __start; defaulting to 00000000004000b0 getopt.o: In function `our_malloc': getopt.o(.text+0x18): undefined reference to `malloc' getopt.o(.text+0x4c): undefined reference to `dcgettext' getopt.o(.text+0x5c): undefined reference to `stderr' getopt.o(.text+0x78): undefined reference to `fprintf' getopt.o(.text+0x8c): undefined reference to `exit' getopt.o: In function `our_realloc': getopt.o(.text+0xbc): undefined reference to `realloc' getopt.o(.text+0xfc): undefined reference to `dcgettext' getopt.o(.text+0x10c): undefined reference to `stderr' getopt.o(.text+0x128): undefined reference to `fprintf' getopt.o(.text+0x13c): undefined reference to `exit' getopt.o: In function `normalize': getopt.o(.text+0x1b0): undefined reference to `strlen' getopt.o(.text+0x1f0): undefined reference to `strcpy' getopt.o(.text+0x23c): undefined reference to `strlen' getopt.o(.text+0x304): undefined reference to `__ctype_b_loc' getopt.o(.text+0x3b0): undefined reference to `free' getopt.o: In function `generate_output': getopt.o(.text+0x3d8): undefined reference to `opterr' getopt.o(.text+0x430): undefined reference to `optind' getopt.o(.text+0x43c): undefined reference to `opterr' getopt.o(.text+0x46c): undefined reference to `getopt_long_only' getopt.o(.text+0x4cc): undefined reference to `printf' getopt.o(.text+0x4e4): undefined reference to `strchr' getopt.o(.text+0x504): undefined reference to `optarg' getopt.o(.text+0x540): undefined reference to `printf' getopt.o(.text+0x554): undefined refermake[1]: *** Deleting file `getopt' make[1]: *** [getopt] Interrupt make: *** [all] Interrupt This package compiles completely if I use an -mabi=n32 flag for gcc, but the executable won't run on our -mabi=32 compiled kernel. Can anybody help with the following: 1) What's the difference between -mabi=32 and -mabi=n32? 2) What should I do to compile util-linux with -mabi=32? Thanks, Alex From ths@networkno.de Thu Mar 24 12:01:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Mar 2005 12:01:34 +0000 (GMT) Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:62346 "EHLO mx02.qsc.de") by linux-mips.org with ESMTP id ; Thu, 24 Mar 2005 12:01:19 +0000 Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1DER1R-0002DL-00; Thu, 24 Mar 2005 13:01:09 +0100 Received: from ths by hattusa.textio with local (Exim 4.50) id 1DER1R-0001Nv-LH; Thu, 24 Mar 2005 13:01:09 +0100 Date: Thu, 24 Mar 2005 13:01:09 +0100 To: Alex Gonzalez Cc: debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: ABI incompatibility when building util-linux Message-ID: <20050324120109.GI8876@hattusa.textio> References: <1111663536.27220.32.camel@euskadi.packetvision> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111663536.27220.32.camel@euskadi.packetvision> User-Agent: Mutt/1.5.6+20040907i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 1354 Lines: 34 Alex Gonzalez wrote: > Hi, > > When compiling the util-linux-2.12q sources, I get the following linker > ABI incompatibility error: [snip] > mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" getopt.c -o getopt.o > mips64-linux-gnu-gcc: -t: linker input file unused because linking not done > mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done The compiler is broken and fails to recognize -Wl,-t -Wl,-EB as linker options. > mips64-linux-gnu-ld -V -static -t -EB getopt.o -o getopt > GNU ld version 2.13-mips64linux-031001 20020920 This toolchain is very old, and unlikely to work correctly for mips64. [snip] > Can anybody help with the following: > > 1) What's the difference between -mabi=32 and -mabi=n32? n32 means 64bit wide registers and 32bit address space. It runs only on a 64bit kernel. > 2) What should I do to compile util-linux with -mabi=32? Use either a mips-linux targeted toolchain (instead of mips64-linux), or upgrade to gcc 3.3/binutils 2.15, which fixed some known bugs in that area. Thiemo From kumba@gentoo.org Thu Mar 24 13:48:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Mar 2005 13:48:52 +0000 (GMT) Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:52440 "EHLO rwcrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Thu, 24 Mar 2005 13:48:35 +0000 Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45]) by comcast.net (rwcrmhc12) with ESMTP id <2005032413482801400sfhuce>; Thu, 24 Mar 2005 13:48:28 +0000 Message-ID: <4242C54B.3010306@gentoo.org> Date: Thu, 24 Mar 2005 08:48:59 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Alex Gonzalez , debian-mips@lists.debian.org Subject: Re: ABI incompatibility when building util-linux References: <1111663536.27220.32.camel@euskadi.packetvision> <20050324120109.GI8876@hattusa.textio> In-Reply-To: <20050324120109.GI8876@hattusa.textio> Content-Type: multipart/mixed; boundary="------------080301080206020304000809" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1657 Lines: 50 This is a multi-part message in MIME format. --------------080301080206020304000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thiemo Seufer wrote: > > n32 means 64bit wide registers and 32bit address space. It runs only on > a 64bit kernel. > A bit off topic, but it reminded me nonetheless. Anyone trying to build a new version of procpcs (>3.4.2) under mips64 will likely need this patch. Unsure what the reasoning behind this bit was in procps, but it assumes that n32 is usable on a mips64 system (atleast, my understanding of the conditional is that), and thus defines KLONG to long long on mips64, which breaks 'ps' on these systems (you get a nice sigsev). Thought it'd be useful to pass along. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond --------------080301080206020304000809 Content-Type: text/plain; name="procps-mips-n32_isnt_usable_on_mips64_yet.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="procps-mips-n32_isnt_usable_on_mips64_yet.patch" diff -Naurp procps-3.2.4.orig/proc/procps.h procps-3.2.4/proc/procps.h --- procps-3.2.4.orig/proc/procps.h 2004-08-20 18:40:13 -0400 +++ procps-3.2.4/proc/procps.h 2005-02-28 10:38:05 -0500 @@ -31,7 +31,7 @@ // // Unknown: PA-RISC and zSeries // -#if defined(k64test) || defined(_ABIN32) +#if defined(k64test) #define KLONG long long // not typedef; want "unsigned KLONG" to work #define KLF "L" #define STRTOUKL strtoull --------------080301080206020304000809-- From drow@nevyn.them.org Thu Mar 24 14:51:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Mar 2005 14:51:57 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:43938 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Thu, 24 Mar 2005 14:51:42 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DETgn-0006k0-Nj; Thu, 24 Mar 2005 09:52:01 -0500 Date: Thu, 24 Mar 2005 09:52:01 -0500 From: Daniel Jacobowitz To: Thiemo Seufer Cc: Alex Gonzalez , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: ABI incompatibility when building util-linux Message-ID: <20050324145201.GA25778@nevyn.them.org> Mail-Followup-To: Thiemo Seufer , Alex Gonzalez , debian-mips@lists.debian.org, linux-mips@linux-mips.org References: <1111663536.27220.32.camel@euskadi.packetvision> <20050324120109.GI8876@hattusa.textio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050324120109.GI8876@hattusa.textio> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 1473 Lines: 32 On Thu, Mar 24, 2005 at 01:01:09PM +0100, Thiemo Seufer wrote: > Alex Gonzalez wrote: > > Hi, > > > > When compiling the util-linux-2.12q sources, I get the following linker > > ABI incompatibility error: > [snip] > > mips64-linux-gnu-gcc -c -O2 -pipe -march=rm9000 -mabi=32 -static -mips4 -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED -Wl,-t -Wl,-EB -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" getopt.c -o getopt.o > > mips64-linux-gnu-gcc: -t: linker input file unused because linking not done > > mips64-linux-gnu-gcc: -EB: linker input file unused because linking not done > > The compiler is broken and fails to recognize -Wl,-t -Wl,-EB as linker > options. Actually, the compiler's fine. It's always issued this warning for linker options, whether or not they are input files. > > mips64-linux-gnu-ld -V -static -t -EB getopt.o -o getopt > > GNU ld version 2.13-mips64linux-031001 20020920 > > This toolchain is very old, and unlikely to work correctly for mips64. It should be binary compatible with current toolchains, more or less; I've used it before. The problem is in Alex's environment. Alex, whatever you're setting to force use of the cross compilers, it's wrong. You should _never_ link directly with ld. That's the error here. -- Daniel Jacobowitz CodeSourcery, LLC From kumba@gentoo.org Fri Mar 25 03:24:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 03:24:53 +0000 (GMT) Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:18921 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 03:24:37 +0000 Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45]) by comcast.net (sccrmhc11) with ESMTP id <2005032503242801100lpuc7e>; Fri, 25 Mar 2005 03:24:28 +0000 Message-ID: <4243848D.3030201@gentoo.org> Date: Thu, 24 Mar 2005 22:25:01 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List CC: Ralf Baechle Subject: [PATCH]: Set CONFIG_SECCOMP default to 'n' Content-Type: multipart/mixed; boundary="------------090703020702080105040900" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1255 Lines: 38 This is a multi-part message in MIME format. --------------090703020702080105040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As I recently learned, CONFIG_SECCOMP's default value is "y", and this can cause the build to fail until the remaining bits of this feature are committed. The attached patch changes the default to "n". --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond --------------090703020702080105040900 Content-Type: text/plain; name="misc-2.6.12-seccomp-no-default.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="misc-2.6.12-seccomp-no-default.patch" --- arch/mips/Kconfig.orig 2005-03-21 14:31:08.757419840 -0500 +++ arch/mips/Kconfig 2005-03-21 14:31:20.955565440 -0500 @@ -1422,7 +1422,7 @@ config BINFMT_ELF32 config SECCOMP bool "Enable seccomp to safely compute untrusted bytecode" depends on PROC_FS && BROKEN - default y + default n help This kernel feature is useful for number crunching applications that may need to compute untrusted bytecode during their --------------090703020702080105040900-- From em@realmagic.fr Fri Mar 25 14:43:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 14:43:57 +0000 (GMT) Received: from emmental.realmagic.fr ([IPv6:::ffff:82.229.218.57]:51405 "EHLO bunker.france.sdesigns.com") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 14:43:42 +0000 Received: from [172.27.0.88] (nikita.france.sdesigns.com [172.27.0.88]) by bunker.france.sdesigns.com (Postfix) with ESMTP id BC4AB9D4A0 for ; Fri, 25 Mar 2005 15:43:40 +0100 (CET) Subject: kernel oops -> bootloader path From: Emmanuel Michon To: linux-mips@linux-mips.org Content-Type: text/plain Organization: REALmagic France SAS Message-Id: <1111761820.28989.407.camel@nikita.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 25 Mar 2005 15:43:40 +0100 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Content-Length: 242 Lines: 12 Hi, is there a `standard' mechanism by which a fatal mips linux kernel error drops the user back to the bootloader (typically YAMON) for stack review / disassemble / maybe... resume? Is this the purpose of BEV bit? Sincerely yours, E.M. From martini@c2micro.com Fri Mar 25 19:26:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 19:26:32 +0000 (GMT) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:47237 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 19:26:16 +0000 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id 45E4E25C95F for ; Fri, 25 Mar 2005 11:26:07 -0800 (PST) Message-ID: <42446555.6090005@c2micro.com> Date: Fri, 25 Mar 2005 11:24:05 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Observations on LLSC and SMP References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> <20050316120647.GB8563@linux-mips.org> In-Reply-To: <20050316120647.GB8563@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 1732 Lines: 59 In include/asm-mips/ atomic.h, bitops.h and system.h there are a bunch of inline functions which contain this logic: if (cpu_has_llsc && R10000_LLSC_WAR) { __asm__ (stuff) } else if (cpu_has_llsc) { __asm__ (other stuff) } else { C lang stuff; } My two observations relate to both code size and runtime performance. These observations don't affect my situation, so I'm not inclined to spend a bunch of time on it, but maybe someone else is interested. This should be especially interesting since these inline functions are used all over the kernel, so it might actually make a marginally significant difference. I suppose there's a reason this code is the way it is. If so, feel free to ignore me or flame away. 1. If the first part of the if were an ifdef instead it would result in a code size reduction as well as a runtime performance gain. 2. In atomic.h the "C lang stuff" is wrapped with a spinlock. In the SMP case the spinlock will result in code that contains ll and sc instructions, so I infer that there are no SMP system configs that use CPUs that don't have the ll and sc instructions. Paranoid version: ----- if (cpu_has_llsc) { #ifdef R10000_LLSC_WAR __asm__ (stuff) #else __asm__ (other stuff) #endif } else { #ifdef CONFIG_SMP panic("SMP on CPUs with no LLSC is broken\n"); #else C lang stuff; #endif } ----- Most efficient version: ----- #ifndef CONFIG_SMP if (cpu_has_llsc) #endif { #ifdef R10000_LLSC_WAR __asm__ (stuff) #else __asm__ (other stuff) #endif } ----- From drow@nevyn.them.org Fri Mar 25 19:37:27 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 19:37:49 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:58598 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 19:37:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DEud5-00060b-Rl; Fri, 25 Mar 2005 14:37:59 -0500 Date: Fri, 25 Mar 2005 14:37:59 -0500 From: Daniel Jacobowitz To: Ed Martini Cc: linux-mips@linux-mips.org Subject: Re: Observations on LLSC and SMP Message-ID: <20050325193759.GA23046@nevyn.them.org> References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> <20050316120647.GB8563@linux-mips.org> <42446555.6090005@c2micro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42446555.6090005@c2micro.com> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 731 Lines: 19 On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote: > 1. If the first part of the if were an ifdef instead it would result in > a code size reduction as well as a runtime performance gain. You should spend a little time playing with an optimizing compiler. They're capable of working out when a condition will always be false. > 2. In atomic.h the "C lang stuff" is wrapped with a spinlock. In the > SMP case the spinlock will result in code that contains ll and sc > instructions, so I infer that there are no SMP system configs that use > CPUs that don't have the ll and sc instructions. That's correct. It is not practical to implement SMP without a mutex primitive. -- Daniel Jacobowitz CodeSourcery, LLC From pf@net.alphadv.de Fri Mar 25 20:03:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 20:03:48 +0000 (GMT) Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:22533 "EHLO mail.alphastar.de") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 20:03:32 +0000 Received: by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==) for ; Fri, 25 Mar 2005 21:01:23 +0100 Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id j2PK0LrM000544; Fri, 25 Mar 2005 21:00:21 +0100 Received: from localhost (pf@localhost) by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id UAA00787; Fri, 25 Mar 2005 20:59:59 +0100 Date: Fri, 25 Mar 2005 20:59:59 +0100 (CET) From: peter fuerst To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: [PATCH] serial console (drivers/serial/ip22zilog.c) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: pf@net.alphadv.de Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pf@net.alphadv.de Precedence: bulk X-list: linux-mips Content-Length: 974 Lines: 36 Hi, here's a patch to make serial console work on IP2X machines. I submitted it already on Dec 20, Kaj-Michael Lang submitted it again on Feb 14, but somehow it didn't find its way into CVS yet. Please apply. Thank you. with best regards pf --- snip --------------------------------------------------------------- diff -Nau -b -B drivers/serial/ip22zilog.c.1.16 drivers/serial/ip22zilog.c --- drivers/serial/ip22zilog.c.1.16 Fri Dec 3 06:07:38 2004 +++ drivers/serial/ip22zilog.c Sat Feb 12 15:14:48 2005 @@ -881,6 +881,7 @@ up->cflag = termios->c_cflag; ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port)); + uart_update_timeout(port, termios->c_cflag, baud); spin_unlock_irqrestore(&up->port.lock, flags); } @@ -1047,6 +1048,8 @@ } con->cflag = cflag | CS8; /* 8N1 */ + + uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud); } static int __init ip22zilog_console_setup(struct console *con, char *options) From pf@net.alphadv.de Fri Mar 25 20:04:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 20:04:30 +0000 (GMT) Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:22021 "EHLO mail.alphastar.de") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 20:03:33 +0000 Received: from SNaIlmail.Peter (212.144.145.222) by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==) for ; Fri, 25 Mar 2005 21:01:20 +0100 Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id j2PK0LrO000544; Fri, 25 Mar 2005 21:00:22 +0100 Received: from localhost (pf@localhost) by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id UAA00779; Fri, 25 Mar 2005 20:56:07 +0100 Date: Fri, 25 Mar 2005 20:56:07 +0100 (CET) From: peter fuerst To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: [PATCH] r4k_dma_cache_inv (arch/mips/mm/c-r4k.c) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: pf@net.alphadv.de Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pf@net.alphadv.de Precedence: bulk X-list: linux-mips Content-Length: 1404 Lines: 56 Hi, here's a (long outstanding) patch, that let's `r4k_dma_cache_inv' do what it should do, instead of being a mere copy of `r4k_dma_cache_wback_inv'. (There really are machines, where we occasionaly can't avoid to invalidate cache(s) :) Please apply. Thank you. with best regards pf --- snip --------------------------------------------------------------- diff -Nau -b -B arch/mips/mm/c-r4k.c.1.107 arch/mips/mm/c-r4k.c --- arch/mips/mm/c-r4k.c.1.107 Fri Mar 18 17:36:53 2005 +++ arch/mips/mm/c-r4k.c Tue Mar 22 23:35:23 2005 @@ -668,32 +668,24 @@ if (cpu_has_subset_pcaches) { unsigned long sc_lsize = current_cpu_data.scache.linesz; - if (size >= scache_size) { - r4k_blast_scache(); - return; - } - a = addr & ~(sc_lsize - 1); end = (addr + size - 1) & ~(sc_lsize - 1); while (1) { - flush_scache_line(a); /* Hit_Writeback_Inv_SD */ + invalidate_scache_line(a); /* Hit_Invalidate_SD/S */ if (a == end) break; a += sc_lsize; } return; } - - if (size >= dcache_size) { - r4k_blast_dcache(); - } else { + { unsigned long dc_lsize = current_cpu_data.dcache.linesz; R4600_HIT_CACHEOP_WAR_IMPL; a = addr & ~(dc_lsize - 1); end = (addr + size - 1) & ~(dc_lsize - 1); while (1) { - flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + invalidate_dcache_line(a); /* Hit_Invalidate_D */ if (a == end) break; a += dc_lsize; From martini@c2micro.com Fri Mar 25 22:48:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 22:48:50 +0000 (GMT) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:23727 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 22:48:35 +0000 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id D128F25C95F; Fri, 25 Mar 2005 14:48:06 -0800 (PST) Message-ID: <424494AC.7020407@c2micro.com> Date: Fri, 25 Mar 2005 14:46:04 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: linux-mips@linux-mips.org Subject: Re: Observations on LLSC and SMP References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> <20050316120647.GB8563@linux-mips.org> <42446555.6090005@c2micro.com> <20050325193759.GA23046@nevyn.them.org> In-Reply-To: <20050325193759.GA23046@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 572 Lines: 19 Daniel Jacobowitz wrote: >On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote: > > >>1. If the first part of the if were an ifdef instead it would result in >>a code size reduction as well as a runtime performance gain. >> >> > >You should spend a little time playing with an optimizing compiler. >They're capable of working out when a condition will always be false. > > Yes, but in the case where R10000_LLSC_WAR is true, but cpu_has_llsc returns false there are still two wasted tests, and two blocks of code that the compiler can't optimize out. From drow@nevyn.them.org Fri Mar 25 22:53:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 22:53:16 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:41425 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 22:53:01 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DExgN-0003Jv-Hf; Fri, 25 Mar 2005 17:53:35 -0500 Date: Fri, 25 Mar 2005 17:53:35 -0500 From: Daniel Jacobowitz To: Ed Martini Cc: linux-mips@linux-mips.org Subject: Re: Observations on LLSC and SMP Message-ID: <20050325225335.GA12669@nevyn.them.org> References: <4230DB4C.7090103@c2micro.com> <20050314110101.GF7759@linux-mips.org> <423763B9.2000907@c2micro.com> <20050316120647.GB8563@linux-mips.org> <42446555.6090005@c2micro.com> <20050325193759.GA23046@nevyn.them.org> <424494AC.7020407@c2micro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424494AC.7020407@c2micro.com> User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 813 Lines: 25 On Fri, Mar 25, 2005 at 02:46:04PM -0800, Ed Martini wrote: > Daniel Jacobowitz wrote: > > >On Fri, Mar 25, 2005 at 11:24:05AM -0800, Ed Martini wrote: > > > > > >>1. If the first part of the if were an ifdef instead it would result in > >>a code size reduction as well as a runtime performance gain. > >> > >> > > > >You should spend a little time playing with an optimizing compiler. > >They're capable of working out when a condition will always be false. > > > > > Yes, but in the case where R10000_LLSC_WAR is true, but cpu_has_llsc > returns false there are still two wasted tests, and two blocks of code > that the compiler can't optimize out. Not only is cpu_has_llsc often a constant, R10000_LLSC_WAR will never be true if the CPU does not have LL/SC. -- Daniel Jacobowitz CodeSourcery, LLC From ddaney@avtrex.com Fri Mar 25 22:59:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 22:59:23 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:44329 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 22:59:06 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Mar 2005 14:58:46 -0800 Message-ID: <424497A4.4040206@avtrex.com> Date: Fri, 25 Mar 2005 14:58:44 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [Patch] Changes to make 2.4 build with gcc-4.0.0... Content-Type: multipart/mixed; boundary="------------070208020208050408030304" X-OriginalArrivalTime: 25 Mar 2005 22:58:46.0768 (UTC) FILETIME=[336AC700:01C5318E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Content-Length: 12372 Lines: 385 This is a multi-part message in MIME format. --------------070208020208050408030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just tried building my 2.4.29 kernel with gcc-4.0.0. The attached patch is needed. It seems to run fine but I have not extensively tested it. The changes to include/asm/uaccess.h and include/linux/byteorder/swab.h are mostly back ports from CVS HEAD. The rest is just random things that I had to change to make it work. In addition to these changes you need the changes that are floating around on the list to asm-mips/ptrace.h, arch/mips/kernel/signal.c and arch/mips/kernel/syscall.c so that it will run when compiled with gcc-3.4 The diffs are from my internal CVS so version numbers will not match those on linux-mips' CVS. David Daney. --------------070208020208050408030304 Content-Type: text/plain; name="4.0.0.diffx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="4.0.0.diffx" Index: drivers/i2c/i2c-core.c =================================================================== RCS file: /linux/linux/drivers/i2c/i2c-core.c,v retrieving revision 1.3 diff -c -p -r1.3 i2c-core.c *** drivers/i2c/i2c-core.c 2 Dec 2004 19:50:22 -0000 1.3 --- drivers/i2c/i2c-core.c 25 Mar 2005 22:22:12 -0000 *************** int i2c_master_send(struct i2c_client *c *** 754,760 **** msg.addr = client->addr; msg.flags = client->flags & I2C_M_TEN; msg.len = count; ! (const char *)msg.buf = buf; DEB2(printk(KERN_DEBUG "i2c-core.o: master_send: writing %d bytes on %s.\n", count,client->adapter->name)); --- 754,760 ---- msg.addr = client->addr; msg.flags = client->flags & I2C_M_TEN; msg.len = count; ! msg.buf = (__u8 *)buf; DEB2(printk(KERN_DEBUG "i2c-core.o: master_send: writing %d bytes on %s.\n", count,client->adapter->name)); *************** int i2c_master_recv(struct i2c_client *c *** 784,790 **** msg.flags = client->flags & I2C_M_TEN; msg.flags |= I2C_M_RD; msg.len = count; ! msg.buf = buf; DEB2(printk(KERN_DEBUG "i2c-core.o: master_recv: reading %d bytes on %s.\n", count,client->adapter->name)); --- 784,790 ---- msg.flags = client->flags & I2C_M_TEN; msg.flags |= I2C_M_RD; msg.len = count; ! msg.buf = (__u8 *)buf; DEB2(printk(KERN_DEBUG "i2c-core.o: master_recv: reading %d bytes on %s.\n", count,client->adapter->name)); Index: drivers/usb/inode.c =================================================================== RCS file: /linux/linux/drivers/usb/inode.c,v retrieving revision 1.1.1.1 diff -c -p -r1.1.1.1 inode.c *** drivers/usb/inode.c 26 Feb 2004 19:15:00 -0000 1.1.1.1 --- drivers/usb/inode.c 25 Mar 2005 22:22:16 -0000 *************** *** 42,47 **** --- 42,49 ---- #include /* --------------------------------------------------------------------- */ + static struct file_operations usbdevfs_bus_file_operations; + static struct inode_operations usbdevfs_bus_inode_operations; /* * This list of superblocks is still used, Index: include/asm-mips/uaccess.h =================================================================== RCS file: /linux/linux/include/asm-mips/uaccess.h,v retrieving revision 1.3 diff -c -p -r1.3 uaccess.h *** include/asm-mips/uaccess.h 5 Feb 2005 01:03:58 -0000 1.3 --- include/asm-mips/uaccess.h 25 Mar 2005 22:22:17 -0000 *************** static inline int verify_area(int type, *** 149,155 **** * Returns zero on success, or -EFAULT on error. */ #define put_user(x,ptr) \ ! __put_user_check((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr))) /* * get_user: - Get a simple variable from user space. --- 149,155 ---- * Returns zero on success, or -EFAULT on error. */ #define put_user(x,ptr) \ ! __put_user_check((x),(ptr),sizeof(*(ptr))) /* * get_user: - Get a simple variable from user space. *************** static inline int verify_area(int type, *** 169,175 **** * On error, the variable @x is set to zero. */ #define get_user(x,ptr) \ ! __get_user_check((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr))) /* * __put_user: - Write a simple value into user space, with less checking. --- 169,175 ---- * On error, the variable @x is set to zero. */ #define get_user(x,ptr) \ ! __get_user_check((x),(ptr),sizeof(*(ptr))) /* * __put_user: - Write a simple value into user space, with less checking. *************** static inline int verify_area(int type, *** 191,197 **** * Returns zero on success, or -EFAULT on error. */ #define __put_user(x,ptr) \ ! __put_user_nocheck((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr))) /* * __get_user: - Get a simple variable from user space, with less checking. --- 191,197 ---- * Returns zero on success, or -EFAULT on error. */ #define __put_user(x,ptr) \ ! __put_user_nocheck((x),(ptr),sizeof(*(ptr))) /* * __get_user: - Get a simple variable from user space, with less checking. *************** static inline int verify_area(int type, *** 214,220 **** * On error, the variable @x is set to zero. */ #define __get_user(x,ptr) \ ! __get_user_nocheck((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr))) struct __large_struct { unsigned long buf[100]; }; #define __m(x) (*(struct __large_struct *)(x)) --- 214,220 ---- * On error, the variable @x is set to zero. */ #define __get_user(x,ptr) \ ! __get_user_nocheck((x),(ptr),sizeof(*(ptr))) struct __large_struct { unsigned long buf[100]; }; #define __m(x) (*(struct __large_struct *)(x)) *************** struct __large_struct { unsigned long bu *** 232,238 **** #define __get_user_nocheck(x,ptr,size) \ ({ \ long __gu_err = 0; \ ! __typeof(*(ptr)) __gu_val = 0; \ long __gu_addr; \ __gu_addr = (long) (ptr); \ switch (size) { \ --- 232,238 ---- #define __get_user_nocheck(x,ptr,size) \ ({ \ long __gu_err = 0; \ ! __typeof(*(ptr)) __gu_val = (__typeof(*(ptr))) 0; \ long __gu_addr; \ __gu_addr = (long) (ptr); \ switch (size) { \ *************** struct __large_struct { unsigned long bu *** 248,254 **** #define __get_user_check(x,ptr,size) \ ({ \ ! __typeof__(*(ptr)) __gu_val = 0; \ long __gu_addr = (long) (ptr); \ long __gu_err; \ \ --- 248,254 ---- #define __get_user_check(x,ptr,size) \ ({ \ ! __typeof__(*(ptr)) __gu_val = 0; \ long __gu_addr = (long) (ptr); \ long __gu_err; \ \ Index: include/linux/fs.h =================================================================== RCS file: /linux/linux/include/linux/fs.h,v retrieving revision 1.5 diff -c -p -r1.5 fs.h *** include/linux/fs.h 5 Feb 2005 01:03:57 -0000 1.5 --- include/linux/fs.h 25 Mar 2005 22:22:18 -0000 *************** static inline int is_mounted(kdev_t dev) *** 1570,1576 **** unsigned long generate_cluster(kdev_t, int b[], int); unsigned long generate_cluster_swab32(kdev_t, int b[], int); extern kdev_t ROOT_DEV; - extern char root_device_name[]; extern void show_buffers(void); --- 1570,1575 ---- Index: include/linux/i2c.h =================================================================== RCS file: /linux/linux/include/linux/i2c.h,v retrieving revision 1.5 diff -c -p -r1.5 i2c.h *** include/linux/i2c.h 5 Feb 2005 01:03:58 -0000 1.5 --- include/linux/i2c.h 25 Mar 2005 22:22:18 -0000 *************** extern int i2c_master_recv(struct i2c_cl *** 70,76 **** /* Transfer num messages. */ ! extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int num); /* * Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor. --- 70,76 ---- /* Transfer num messages. */ ! extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg, int num); /* * Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor. *************** struct i2c_algorithm { *** 197,203 **** to NULL. If an adapter algorithm can do SMBus access, set smbus_xfer. If set to NULL, the SMBus protocol is simulated using common I2C messages */ ! int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[], int num); int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, unsigned short flags, char read_write, --- 197,203 ---- to NULL. If an adapter algorithm can do SMBus access, set smbus_xfer. If set to NULL, the SMBus protocol is simulated using common I2C messages */ ! int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs, int num); int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, unsigned short flags, char read_write, Index: include/linux/usbdevice_fs.h =================================================================== RCS file: /linux/linux/include/linux/usbdevice_fs.h,v retrieving revision 1.1.1.1 diff -c -p -r1.1.1.1 usbdevice_fs.h *** include/linux/usbdevice_fs.h 26 Feb 2004 19:15:29 -0000 1.1.1.1 --- include/linux/usbdevice_fs.h 25 Mar 2005 22:22:21 -0000 *************** extern struct file_operations usbdevfs_d *** 185,192 **** extern struct file_operations usbdevfs_devices_fops; extern struct file_operations usbdevfs_device_file_operations; extern struct inode_operations usbdevfs_device_inode_operations; - extern struct inode_operations usbdevfs_bus_inode_operations; - extern struct file_operations usbdevfs_bus_file_operations; extern void usbdevfs_conn_disc_event(void); #endif /* __KERNEL__ */ --- 185,190 ---- Index: include/linux/byteorder/swab.h =================================================================== RCS file: /linux/linux/include/linux/byteorder/swab.h,v retrieving revision 1.1.1.1 diff -c -p -r1.1.1.1 swab.h *** include/linux/byteorder/swab.h 26 Feb 2004 19:15:29 -0000 1.1.1.1 --- include/linux/byteorder/swab.h 25 Mar 2005 22:22:21 -0000 *************** *** 156,162 **** #endif /* OPTIMIZE */ ! static __inline__ __const__ __u16 __fswab16(__u16 x) { return __arch__swab16(x); } --- 156,162 ---- #endif /* OPTIMIZE */ ! static __inline__ __u16 __fswab16(__u16 x) { return __arch__swab16(x); } *************** static __inline__ void __swab16s(__u16 * *** 169,175 **** __arch__swab16s(addr); } ! static __inline__ __const__ __u32 __fswab24(__u32 x) { return __arch__swab24(x); } --- 169,175 ---- __arch__swab16s(addr); } ! static __inline__ __u32 __fswab24(__u32 x) { return __arch__swab24(x); } *************** static __inline__ void __swab24s(__u32 * *** 182,188 **** __arch__swab24s(addr); } ! static __inline__ __const__ __u32 __fswab32(__u32 x) { return __arch__swab32(x); } --- 182,188 ---- __arch__swab24s(addr); } ! static __inline__ __u32 __fswab32(__u32 x) { return __arch__swab32(x); } *************** static __inline__ void __swab32s(__u32 * *** 196,202 **** } #ifdef __BYTEORDER_HAS_U64__ ! static __inline__ __const__ __u64 __fswab64(__u64 x) { # ifdef __SWAB_64_THRU_32__ __u32 h = x >> 32; --- 196,202 ---- } #ifdef __BYTEORDER_HAS_U64__ ! static __inline__ __u64 __fswab64(__u64 x) { # ifdef __SWAB_64_THRU_32__ __u32 h = x >> 32; Index: include/net/icmp.h =================================================================== RCS file: /linux/linux/include/net/icmp.h,v retrieving revision 1.1.1.1 diff -c -p -r1.1.1.1 icmp.h *** include/net/icmp.h 26 Feb 2004 19:15:21 -0000 1.1.1.1 --- include/net/icmp.h 25 Mar 2005 22:22:21 -0000 *************** *** 23,28 **** --- 23,29 ---- #include #include + #include struct icmp_err { int errno; Index: include/net/ipv6.h =================================================================== RCS file: /linux/linux/include/net/ipv6.h,v retrieving revision 1.1.1.2 diff -c -p -r1.1.1.2 ipv6.h *** include/net/ipv6.h 1 Dec 2004 21:52:24 -0000 1.1.1.2 --- include/net/ipv6.h 25 Mar 2005 22:22:21 -0000 *************** *** 19,24 **** --- 19,25 ---- #include #include #include + #include #define SIN6_LEN_RFC2133 24 --------------070208020208050408030304-- From maillist@jg555.com Fri Mar 25 23:31:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Mar 2005 23:31:53 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:37000 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Fri, 25 Mar 2005 23:31:38 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Fri, 25 Mar 2005 15:31:36 -0800 id 0000C3D8.42449F58.00007609 Message-ID: <42449F47.8010002@jg555.com> Date: Fri, 25 Mar 2005 15:31:19 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: Build 64bit on RaQ2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 352 Lines: 13 Has anyone had any luck compiling a 64 bit version on the RaQ2. I can get it to compile but, it locks up during boot up. elf64: 00080000 - 0042fd3f (ffffffff,803e6000) (ffffffff,8000000) elf64: ffffffff,80080000 (8008000) 3731589t + 134331t That's all I got during bootup, no error messages or anything. -- ---- Jim Gifford maillist@jg555.com From kumba@gentoo.org Sat Mar 26 00:38:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Mar 2005 00:38:55 +0000 (GMT) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:56255 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Sat, 26 Mar 2005 00:38:41 +0000 Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45]) by comcast.net (rwcrmhc13) with ESMTP id <2005032600383301500p3gjme>; Sat, 26 Mar 2005 00:38:34 +0000 Message-ID: <4244AEF3.7010201@gentoo.org> Date: Fri, 25 Mar 2005 19:38:11 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: Linux MIPS List Subject: Re: Build 64bit on RaQ2 References: <42449F47.8010002@jg555.com> In-Reply-To: <42449F47.8010002@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 950 Lines: 25 Jim Gifford wrote: > Has anyone had any luck compiling a 64 bit version on the RaQ2. I can > get it to compile but, it locks up during boot up. > > elf64: 00080000 - 0042fd3f (ffffffff,803e6000) (ffffffff,8000000) > elf64: ffffffff,80080000 (8008000) 3731589t + 134331t > > That's all I got during bootup, no error messages or anything. Peter Horton had some experimental code in the kernel at one point to try this. I managed to get a 2.6.9 (I think, maybe 2.6.10) mips64 kernel to boot on cobalt, but it was pretty useless. Poor machine was slower than molasses uphill in winter. I believe cobalt would run better using the o64 kernel hack than pure n64 kernel (-mabi=64), but cobalt needs some fixups to its spaces.h before an o64 kernel will build on it. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From pdh@colonel-panic.org Sat Mar 26 09:12:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Mar 2005 09:13:05 +0000 (GMT) Received: from i-83-67-53-76.freedom2surf.net ([IPv6:::ffff:83.67.53.76]:60309 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sat, 26 Mar 2005 09:12:50 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1DF7L8-0000fF-00; Sat, 26 Mar 2005 09:12:18 +0000 Date: Sat, 26 Mar 2005 09:12:18 +0000 To: Jim Gifford Cc: Linux MIPS List Subject: Re: Build 64bit on RaQ2 Message-ID: <20050326091218.GA2471@skeleton-jack> References: <42449F47.8010002@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42449F47.8010002@jg555.com> User-Agent: Mutt/1.5.6+20040907i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 606 Lines: 16 On Fri, Mar 25, 2005 at 03:31:19PM -0800, Jim Gifford wrote: > Has anyone had any luck compiling a 64 bit version on the RaQ2. I can > get it to compile but, it locks up during boot up. > > elf64: 00080000 - 0042fd3f (ffffffff,803e6000) (ffffffff,8000000) > elf64: ffffffff,80080000 (8008000) 3731589t + 134331t > > That's all I got during bootup, no error messages or anything. > As a starting point you need to ensure the "cpu_has_llsc" is false for 64-bit Cobalt kernels. LLD/SCD is broken on RM5230/5231. There is an experimental patch for 2.6.9 on http://www.colonel-panic.org/cobalt-mips. P. From eckhardt@satorlaser.com Sat Mar 26 13:01:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Mar 2005 13:01:37 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:18685 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 26 Mar 2005 13:01:23 +0000 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DFAuo-0008Vw-00 for linux-mips@linux-mips.org; Sat, 26 Mar 2005 14:01:22 +0100 Received: from [80.171.18.129] (helo=d018129.adsl.hansenet.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DFAun-00045P-00 for linux-mips@linux-mips.org; Sat, 26 Mar 2005 14:01:21 +0100 From: Ulrich Eckhardt To: linux-mips@linux-mips.org Subject: board configuration and status registers (BCSR) User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Disposition: inline Organization: Sator Laser GmbH Date: Sat, 26 Mar 2005 13:59:10 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Message-Id: <200503261359.10332.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 381 Lines: 11 Hi! From what I could tell, all the Alchemy based boards have those BCSR, but I wonder where I could find more info about those. The Au1100 programming manual is totally silent on that matter but in the attached hardware itself I couldn't find anything that corresponds to that - or am I just not looking hard enough? Could anybody point me to some docs on that? cheers Uli From ppopov@embeddedalley.com Sat Mar 26 16:24:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Mar 2005 16:24:30 +0000 (GMT) Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:37256 "HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Sat, 26 Mar 2005 16:24:15 +0000 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp007.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2005 16:24:12 -0000 Message-ID: <42458CB1.9040009@embeddedalley.com> Date: Sat, 26 Mar 2005 08:24:17 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org Subject: Re: board configuration and status registers (BCSR) References: <200503261359.10332.eckhardt@satorlaser.com> In-Reply-To: <200503261359.10332.eckhardt@satorlaser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 606 Lines: 14 Ulrich Eckhardt wrote: > Hi! > >>From what I could tell, all the Alchemy based boards have those BCSR, but I > wonder where I could find more info about those. The Au1100 programming > manual is totally silent on that matter but in the attached hardware itself I > couldn't find anything that corresponds to that - or am I just not looking > hard enough? Could anybody point me to some docs on that? AMD ships a CD with all the docs, including the onboard cpld registers. They are described in a spreadsheet. I'm pretty sure they are also available on their web site, under the PCS division. Pete From maillist@jg555.com Tue Mar 29 00:07:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Mar 2005 00:08:13 +0100 (BST) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:21737 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 29 Mar 2005 00:07:57 +0100 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 28 Mar 2005 15:07:55 -0800 id 0000847B.42488E4B.00001A76 Message-ID: <42488DFC.20408@jg555.com> Date: Mon, 28 Mar 2005 15:06:36 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Horton , Linux MIPS List Subject: Re: Build 64bit on RaQ2 References: <42449F47.8010002@jg555.com> <20050326091218.GA2471@skeleton-jack> In-Reply-To: <20050326091218.GA2471@skeleton-jack> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 1635 Lines: 57 Peter Horton wrote: >On Fri, Mar 25, 2005 at 03:31:19PM -0800, Jim Gifford wrote: > > >> Has anyone had any luck compiling a 64 bit version on the RaQ2. I can >>get it to compile but, it locks up during boot up. >> >>elf64: 00080000 - 0042fd3f (ffffffff,803e6000) (ffffffff,8000000) >>elf64: ffffffff,80080000 (8008000) 3731589t + 134331t >> >>That's all I got during bootup, no error messages or anything. >> >> >> > >As a starting point you need to ensure the "cpu_has_llsc" is false for >64-bit Cobalt kernels. LLD/SCD is broken on RM5230/5231. There is an >experimental patch for 2.6.9 on >http://www.colonel-panic.org/cobalt-mips. > >P. > > Peter, Got it to compile, but the tulip driver is giving me fits. I built it as a module and into the kernel 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed 0000:00:07.0: tulip_stop_rxtx() failed -- ---- Jim Gifford maillist@jg555.com From maillist@jg555.com Tue Mar 29 20:01:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Mar 2005 20:01:49 +0100 (BST) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:12704 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 29 Mar 2005 20:01:32 +0100 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 29 Mar 2005 11:01:25 -0800 id 0000846F.4249A605.00001381 Message-ID: <4249A5EE.9070006@jg555.com> Date: Tue, 29 Mar 2005 11:01:02 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux MIPS List Subject: 64bit compile of tulip driver Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 4156 Lines: 87 Under 32bit the tulip driver works fine, but under 64 bit it gives me a lot of grief. First off it continually sends data out the network interface and never negotiates is speed and duplex. Second in the log files all I see is an uninformative message 0000:00:07.0: tulip_stop_rxtx() failed Here is all the bootup information differences I can find on the driver 64 bit Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found! 32 bit Dec 31 16:01:16 lfs tulip0: MII transceiver #1 config 1000 status 7809 advertising 01e1 Dec 31 16:01:16 lfs tulip1: MII transceiver #1 config 1000 status 7809 advertising 01e1. Complete boot log Under a 64 bit compile Dec 31 16:01:29 lfs Linux Tulip driver version 1.1.13 (May 11, 2002) Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047) Dec 31 16:01:29 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:29 lfs tulip0: EEPROM default media type Autosense. Dec 31 16:01:29 lfs tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs eth0: Digital DS21143 Tulip rev 65 at ffffffffb0001400, 00:10:E0:00:32:DE, IRQ 19. Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:0c.0 (0005 -> 0007) Dec 31 16:01:29 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:29 lfs tulip1: EEPROM default media type Autosense. Dec 31 16:01:29 lfs tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs eth1: Digital DS21143 Tulip rev 65 at ffffffffb0001480, 00:10:E0:00:32:DF, IRQ 20. Dec 31 16:01:29 lfs bootlog: Bringing up the eth0 interface...[ OK ] Dec 31 16:01:30 lfs bootlog: Adding IPv4 address 172.16.0.99 to the eth0 interface...[ OK ] Dec 31 16:01:31 lfs bootlog: Setting up default gateway...[ OK ] Dec 31 16:01:32 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:38 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:44 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:50 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:56 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:02 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:08 lfs 0000:00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:12 lfs bootlog: Setting time via pool.ntp.org...[ FAIL ] Under 32 bit Dec 31 16:01:16 lfs Linux Tulip driver version 1.1.13 (May 11, 2002) Dec 31 16:01:16 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047) Dec 31 16:01:16 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:16 lfs tulip0: EEPROM default media type Autosense. Dec 31 16:01:16 lfs tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:16 lfs tulip0: MII transceiver #1 config 1000 status 7809 advertising 01e1. Dec 31 16:01:16 lfs eth0: Digital DS21143 Tulip rev 65 at b0001400, 00:10:E0:00:32:DE, IRQ 19. Dec 31 16:01:16 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:16 lfs tulip1: EEPROM default media type Autosense. Dec 31 16:01:16 lfs tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:16 lfs tulip1: MII transceiver #1 config 1000 status 7809 advertising 01e1. Dec 31 16:01:16 lfs eth1: Digital DS21143 Tulip rev 65 at b0001480, 00:10:E0:00:32:DF, IRQ 20. Dec 31 16:01:17 lfs bootlog: Bringing up the eth0 interface...[ OK ] Dec 31 16:01:17 lfs bootlog: Adding IPv4 address 172.16.0.99 to the eth0 interface...[ OK ] Dec 31 16:01:18 lfs bootlog: Setting up default gateway...[ OK ] Dec 31 16:01:20 lfs eth0: Setting full-duplex based on MII#1 link partner capability of 45e1. Mar 28 08:27:35 lfs bootlog: Setting time via pool.ntp.org...[ OK ] Mar 28 08:27:35 lfs syslog-ng[1457]: STATS: dropped 0 -- ---- Jim Gifford maillist@jg555.com From jbglaw@lug-owl.de Tue Mar 29 20:52:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Mar 2005 20:52:36 +0100 (BST) Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:33757 "EHLO lug-owl.de") by linux-mips.org with ESMTP id ; Tue, 29 Mar 2005 20:52:20 +0100 Received: by lug-owl.de (Postfix, from userid 1001) id 4A625190117; Tue, 29 Mar 2005 21:52:08 +0200 (CEST) Date: Tue, 29 Mar 2005 21:52:08 +0200 From: Jan-Benedict Glaw To: Jim Gifford Cc: Linux MIPS List Subject: Re: 64bit compile of tulip driver Message-ID: <20050329195208.GH17725@lug-owl.de> Mail-Followup-To: Jim Gifford , Linux MIPS List References: <4249A5EE.9070006@jg555.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SdvjNjn6lL3tIsv0" Content-Disposition: inline In-Reply-To: <4249A5EE.9070006@jg555.com> X-Operating-System: Linux mail 2.6.10-rc2-bk5lug-owl X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.6+20040907i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 1781 Lines: 58 --SdvjNjn6lL3tIsv0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-29 11:01:02 -0800, Jim Gifford wrote in message <4249A5EE.9070006@jg555.com>: > Under 32bit the tulip driver works fine, but under 64 bit it gives me a= =20 > lot of grief. >=20 > First off it continually sends data out the network interface and never= =20 > negotiates is speed and duplex. > Second in the log files all I see is an uninformative message=20 > 0000:00:07.0: tulip_stop_rxtx() failed >=20 > Here is all the bootup information differences I can find on the driver > 64 bit > Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found! > Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found! > 32 bit > Dec 31 16:01:16 lfs tulip0: MII transceiver #1 config 1000 status 7809= =20 > advertising 01e1 > Dec 31 16:01:16 lfs tulip1: MII transceiver #1 config 1000 status 7809= =20 > advertising 01e1. That's all wrongly wrapped around. However, where's the patch? MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 = _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg = _ _ O fuer einen Freien Staat voll Freier B=C3=BCrger" | im Internet! | im Ira= k! O O O ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)= ); --SdvjNjn6lL3tIsv0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCSbHoHb1edYOZ4bsRAoMmAKCR24AHvDJRK7KiTaqtqM1uMFrHfQCfaAza kVh06hcandAZ1hLEAn4EGVg= =sdbG -----END PGP SIGNATURE----- --SdvjNjn6lL3tIsv0-- From pdh@colonel-panic.org Tue Mar 29 22:47:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Mar 2005 22:47:19 +0100 (BST) Received: from i-83-67-53-76.freedom2surf.net ([IPv6:::ffff:83.67.53.76]:18119 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 29 Mar 2005 22:47:04 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1DGOXp-0001Lc-00; Tue, 29 Mar 2005 22:46:41 +0100 Date: Tue, 29 Mar 2005 22:46:41 +0100 To: Jim Gifford Cc: Peter Horton , Linux MIPS List Subject: Re: Build 64bit on RaQ2 Message-ID: <20050329214641.GA5152@skeleton-jack> References: <42449F47.8010002@jg555.com> <20050326091218.GA2471@skeleton-jack> <42488DFC.20408@jg555.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42488DFC.20408@jg555.com> User-Agent: Mutt/1.5.6+20040907i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 591 Lines: 19 On Mon, Mar 28, 2005 at 03:06:36PM -0800, Jim Gifford wrote: > > Got it to compile, but the tulip driver is giving me fits. I built > it as a module and into the kernel > > > 0000:00:07.0: tulip_stop_rxtx() failed > 0000:00:07.0: tulip_stop_rxtx() failed > 0000:00:07.0: tulip_stop_rxtx() failed > 0000:00:07.0: tulip_stop_rxtx() failed > 0000:00:07.0: tulip_stop_rxtx() failed > 0000:00:07.0: tulip_stop_rxtx() failed > Tulip driver gave me problems also. I landed up inserting a printk() which made it work, see the patch. I didn't get round to debugging it any further, sorry. P. From maillist@jg555.com Tue Mar 29 23:12:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Mar 2005 23:12:24 +0100 (BST) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:51880 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Tue, 29 Mar 2005 23:12:10 +0100 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 29 Mar 2005 14:12:07 -0800 id 0000C338.4249D2B7.00003F8D Message-ID: <4249D27D.20700@jg555.com> Date: Tue, 29 Mar 2005 14:11:09 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Horton CC: Linux MIPS List Subject: Re: Build 64bit on RaQ2 References: <42449F47.8010002@jg555.com> <20050326091218.GA2471@skeleton-jack> <42488DFC.20408@jg555.com> <20050329214641.GA5152@skeleton-jack> In-Reply-To: <20050329214641.GA5152@skeleton-jack> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maillist@jg555.com Precedence: bulk X-list: linux-mips Content-Length: 840 Lines: 36 Peter Horton wrote: >On Mon, Mar 28, 2005 at 03:06:36PM -0800, Jim Gifford wrote: > > >> Got it to compile, but the tulip driver is giving me fits. I built >>it as a module and into the kernel >> >> >>0000:00:07.0: tulip_stop_rxtx() failed >>0000:00:07.0: tulip_stop_rxtx() failed >>0000:00:07.0: tulip_stop_rxtx() failed >>0000:00:07.0: tulip_stop_rxtx() failed >>0000:00:07.0: tulip_stop_rxtx() failed >>0000:00:07.0: tulip_stop_rxtx() failed >> >> >> > >Tulip driver gave me problems also. I landed up inserting a printk() >which made it work, see the patch. I didn't get round to debugging it >any further, sorry. > >P. > > > I posted a simliar question to the linux-net list, a lot of people don't understand why the driver doesn't work in 64 bit, but works perfectly in 32 bit. -- ---- Jim Gifford maillist@jg555.com From martini@c2micro.com Wed Mar 30 02:47:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Mar 2005 02:47:47 +0100 (BST) Received: from 63-207-7-10.ded.pacbell.net ([IPv6:::ffff:63.207.7.10]:30657 "EHLO cassini.enmediainc.com") by linux-mips.org with ESMTP id ; Wed, 30 Mar 2005 02:47:32 +0100 Received: from [127.0.0.1] (unknown [192.168.10.203]) by cassini.enmediainc.com (Postfix) with ESMTP id 01B4825C95F for ; Tue, 29 Mar 2005 17:47:06 -0800 (PST) Message-ID: <424A04A9.9060703@c2micro.com> Date: Tue, 29 Mar 2005 17:45:13 -0800 From: Ed Martini User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: inconsistent asm macro Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: martini@c2micro.com Precedence: bulk X-list: linux-mips Content-Length: 1262 Lines: 38 In include/asm-mips/interrupt.h, the definition for local_irq_restore is inconsistent in its use of .reorder/.noreorder assembler directives. Other asm macros in interrupt.h are wrapped with '.set push' and '.set pop'. It doesn't seem to be a problem with the 2.96 mipsel-linux- assembler, but it caused me a problem with my 4.0-based toolchain. (As it was the local_irq_restore left the assembler in 'reorder' mode and a stack pointer post-inc was reordered out of the return delay slot where it belonged.) Luckily we have a sharp compiler guy who figured it out. Thanks. As usual, there may be a reason for this, but it took me a whole day to find it, and I thought I'd point it out. Ed Martini $ diff -uN interrupt.h interrupt-new.h --- interrupt.h 2005-03-29 17:35:02.922362384 -0800 +++ interrupt-new.h 2005-03-29 17:33:26.350770293 -0800 @@ -100,6 +100,7 @@ __asm__ ( ".macro\tlocal_irq_restore flags\n\t" + ".set\tpush\n\t" ".set\tnoreorder\n\t" ".set\tnoat\n\t" "mfc0\t$1, $12\n\t" @@ -109,8 +110,7 @@ "or\t\\flags, $1\n\t" "mtc0\t\\flags, $12\n\t" "irq_disable_hazard\n\t" - ".set\tat\n\t" - ".set\treorder\n\t" + ".set\tpop\n\t" ".endm"); From Rishabh@soc-soft.com Wed Mar 30 07:16:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Mar 2005 07:17:03 +0100 (BST) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:63492 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Wed, 30 Mar 2005 07:16:48 +0100 Received: from soc-mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Wed, 30 Mar 2005 11:48:46 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C534F0.5474EE43" Subject: How to compile Target Root Directory X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 30 Mar 2005 11:48:46 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C6C728D@soc-mail.soc-soft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: How to compile Target Root Directory Thread-Index: AcU08FQV94+zLCAvQguY8TuQb9FWRw== From: To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rishabh@soc-soft.com Precedence: bulk X-list: linux-mips Content-Length: 2019 Lines: 50 This is a multi-part message in MIME format. ------_=_NextPart_001_01C534F0.5474EE43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I made some changes with the Memory Management module of MVL 3.1 Linux(2.4.21). Do I need to recompile Target root directory. I am getting exceptions in Kernel bootup(/sbin/init). If so then where can I get the source code for it?=0D Rishabh Kumar Goel The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If= you are not the intended recipient, please notify the sender and delete the message= along with any annexure. You should not disclose, copy or otherwise use the= information contained in the message or any annexure. Any views expressed in this e-mail are= those of the individual sender except where the sender specifically states them to be= the views of SoCrates Software India Pvt Ltd., Bangalore. ------_=_NextPart_001_01C534F0.5474EE43 Content-Type: text/x-vcard; name="Rishabh Kumar Goel.vcf" Content-Transfer-Encoding: base64 Content-Description: Rishabh Kumar Goel.vcf Content-Disposition: attachment; filename="Rishabh Kumar Goel.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkdvZWw7UmlzaGFiaCBLdW1hcg0KRk46UmlzaGFi aCBLdW1hciBHb2VsDQpPUkc6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0IEx0ZC47T1MgJiBE RA0KVElUTEU6U0UNClRFTDtXT1JLO1ZPSUNFOjUxMTAxNjY5ICAgIEV4dDoyNjY5DQpBRFI7V09S SztFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOjtTb2NyYXRlcyBTb2Z0d2FyZSBJbmRpYSBQdnQu IEx0ZC47MTAgQnJpZGUgU3RyZWV0LCA9MEQ9MEFMYW5nZm9yZCBUb3duO0Jhbmc9DQphbG9yZTtL YXJuYXRha2E7NTYwMDI1O0lORElBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFC TEU6U29jcmF0ZXMgU29mdHdhcmUgSW5kaWEgUHZ0LiBMdGQuPTBEPTBBMTAgQnJpZGUgU3RyZWV0 LCA9MEQ9MEFMYW5nZm9yZCBUb3duPQ0KPTBEPTBBQmFuZ2Fsb3JlLCBLYXJuYXRha2EgNTYwMDI1 PTBEPTBBSU5ESUENCkVNQUlMO1BSRUY7SU5URVJORVQ6UmlzaGFiaEBzb2Mtc29mdC5jb20NClJF VjoyMDA1MDIxN1QwNjA4NDJaDQpFTkQ6VkNBUkQNCg== ------_=_NextPart_001_01C534F0.5474EE43-- From tomcs163@yahoo.com.cn Wed Mar 30 08:37:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Mar 2005 08:38:08 +0100 (BST) Received: from web15807.mail.cnb.yahoo.com ([IPv6:::ffff:202.165.102.87]:21855 "HELO web15807.mail.cnb.yahoo.com") by linux-mips.org with SMTP id ; Wed, 30 Mar 2005 08:37:52 +0100 Message-ID: <20050330073742.28983.qmail@web15807.mail.cnb.yahoo.com> Received: from [210.76.108.109] by web15807.mail.cnb.yahoo.com via HTTP; Wed, 30 Mar 2005 15:37:42 CST Date: Wed, 30 Mar 2005 15:37:42 +0800 (CST) From: dfsd df Subject: Some questions about kernel tailoring To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1799187920-1112168262=:27399" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tomcs163@yahoo.com.cn Precedence: bulk X-list: linux-mips Content-Length: 3798 Lines: 67 --0-1799187920-1112168262=:27399 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hello, everybody: Now, I participate to porting linux to MIPS platform. I'm a newbie. I met some questions, I hope somebody can tell me why or give me some hints! thanks! The board is Malta, CPU is MIPS4kc. I downloaded kernel src from ftp.mips.com 1. I use "make zImage" for kernel-2.4.3, everything is ok! But using "make zImage" for kernel-2.4.18, I failed, It could only build a vmlinux file. I find it's because of no rules in arch/mips/boot/Makefile to build zImage. So I modified the arch/mips/boot/Makefile, It worked fine. but when excuted "./mkboot zImage.tmp zImage", It generated a very big zImage file. After noticing "file size exceed", the system delete the zImage file automatically! what's wrong about it? It's ok for kernel-2.4.3. and I can make sure that the mkboot is no problem. 2. I only selectd board and cpu type when compiling the kernel-2.4.3. If using make ,the vmlinux size is about 780k. If using "make zImage", the zImage file is about 580k. I think that's a minimun size by using "make menuconfig". but I use gzip to compress this two files, its size became only 1/3 of their original size. So I'm puzzled why "make zImage" don't use gzip compress method? If so , we can get a more small kernel, isn't it? thanks again! --------------------------------- Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ --0-1799187920-1112168262=:27399 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
Hello, everybody:
     Now, I participate to porting linux to MIPS platform. I'm a newbie.
 
     I met some questions, I hope somebody can tell me why or give me some hints! thanks!
 
The board is Malta, CPU is MIPS4kc. I downloaded kernel src from ftp.mips.com
 
    1. I use "make zImage" for kernel-2.4.3, everything is ok!
 But using "make zImage" for kernel-2.4.18, I failed, It could only build a vmlinux file.
I  find it's because of no rules in arch/mips/boot/Makefile to build zImage.
So I modified the arch/mips/boot/Makefile, It worked fine.
 but when excuted "./mkboot zImage.tmp zImage", It generated a very big zImage file. After noticing "file size exceed", the system delete the zImage file automatically!
 
what's wrong about it? It's ok for kernel-2.4.3. and I can make sure that the mkboot is no problem.
 
2. I only selectd board and cpu type when compiling the kernel-2.4.3.
If using make ,the vmlinux size is about 780k. If using "make zImage", the zImage file is about 580k.
I think that's a minimun size by using "make menuconfig".
but I use gzip to compress this two files, its size became only 1/3 of their original size.
 
So I'm puzzled why "make zImage" don't use gzip compress method? If so , we can get a more small kernel, isn't it?
 
thanks again!
 


Do You Yahoo!?
150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌÃ
ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ
1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ --0-1799187920-1112168262=:27399-- From ppopov@embeddedalley.com Wed Mar 30 08:39:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Mar 2005 08:40:13 +0100 (BST) Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:52661 "HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 30 Mar 2005 08:39:57 +0100 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp002.bizmail.yahoo.com with SMTP; 30 Mar 2005 07:39:55 -0000 Message-ID: <424A57CB.2080206@embeddedalley.com> Date: Tue, 29 Mar 2005 23:39:55 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rishabh@soc-soft.com CC: linux-mips@linux-mips.org Subject: Re: How to compile Target Root Directory References: <4BF47D56A0DD2346A1B8D622C5C5902C6C728D@soc-mail.soc-soft.com> In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C6C728D@soc-mail.soc-soft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1143 Lines: 30 Rishabh@soc-soft.com wrote: > Hi, > > I made some changes with the Memory Management module of MVL 3.1 > Linux(2.4.21). Do I need to recompile Target root directory. You mean the target apps? No. > I am getting exceptions in Kernel bootup(/sbin/init). If so then where can I > get the source code for it? Many places. MontaVista for one, if you're a customer, or whoever gave you the source code. www.google.com is an awesome tool too :) > > Rishabh Kumar Goel Please don't include this text below. You shouldn't be sending priviledged info to a public mailing list. Pete > The information contained in this e-mail message and in any annexure is > confidential to the recipient and may contain privileged information. If you are not > the intended recipient, please notify the sender and delete the message along with > any annexure. You should not disclose, copy or otherwise use the information contained > in the message or any annexure. Any views expressed in this e-mail are those of the > individual sender except where the sender specifically states them to be the views of > SoCrates Software India Pvt Ltd., Bangalore. From stuartl@longlandclan.hopto.org Wed Mar 30 23:20:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Mar 2005 23:20:48 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:16667 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Wed, 30 Mar 2005 23:20:32 +0100 Received: (qmail 27425 invoked by uid 210); 31 Mar 2005 08:20:21 +1000 Received: from 10.0.0.194 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.194):. Processed in 0.097029 secs); 30 Mar 2005 22:20:21 -0000 Received: from unknown (HELO ?10.0.0.194?) (10.0.0.194) by 192.168.5.1 with SMTP; 31 Mar 2005 08:20:20 +1000 Message-ID: <424B2621.20006@longlandclan.hopto.org> Date: Thu, 31 Mar 2005 08:20:17 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dfsd df CC: linux-mips@linux-mips.org Subject: Re: Some questions about kernel tailoring References: <20050330073742.28983.qmail@web15807.mail.cnb.yahoo.com> In-Reply-To: <20050330073742.28983.qmail@web15807.mail.cnb.yahoo.com> X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF125442FC24EC6681048760" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Content-Length: 2732 Lines: 75 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF125442FC24EC6681048760 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit dfsd df wrote: > Hello, everybody: > Now, I participate to porting linux to MIPS platform. I'm a newbie. > > I met some questions, I hope somebody can tell me why or give me > some hints! thanks! > > The board is Malta, CPU is MIPS4kc. I downloaded kernel src from > ftp.mips.com > > 1. I use "make zImage" for kernel-2.4.3, everything is ok! > But using "make zImage" for kernel-2.4.18, I failed, It could only > build a vmlinux file. That's correct... 'vmlinux' is your kernel. mips doesn't use zImages. > I find it's because of no rules in arch/mips/boot/Makefile to build > zImage. > So I modified the arch/mips/boot/Makefile, It worked fine. > but when excuted "./mkboot zImage.tmp zImage", It generated a very big > zImage file. After noticing "file size exceed", the system delete the > zImage file automatically! > Try running mkboot on the vmlinux file. > what's wrong about it? It's ok for kernel-2.4.3. and I can make sure > that the mkboot is no problem. A newer kernel mightn't be a bad idea either... 2.4.3 is very old now. > 2. I only selectd board and cpu type when compiling the kernel-2.4.3. > If using make ,the vmlinux size is about 780k. If using "make zImage", > the zImage file is about 580k. > I think that's a minimun size by using "make menuconfig". > but I use gzip to compress this two files, its size became only 1/3 of > their original size. > > So I'm puzzled why "make zImage" don't use gzip compress method? If so , > we can get a more small kernel, isn't it? > > thanks again! I'll let the guru's chime in here :-) (PS... Please refrain from HTML email on this list) -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ --------------enigFF125442FC24EC6681048760 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSyYmuarJ1mMmSrkRAo/1AJwIx5Pbs3oIvmJEx/GppGGWRQ3hbQCeOVpF OUMmuq/L4cE1NbDDq4Xs/Rk= =zapk -----END PGP SIGNATURE----- --------------enigFF125442FC24EC6681048760-- From tomcs163@yahoo.com.cn Thu Mar 31 02:49:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 02:50:06 +0100 (BST) Received: from web15801.mail.cnb.yahoo.com ([IPv6:::ffff:202.165.102.81]:14220 "HELO web15801.mail.cnb.yahoo.com") by linux-mips.org with SMTP id ; Thu, 31 Mar 2005 02:49:49 +0100 Message-ID: <20050331014935.81645.qmail@web15801.mail.cnb.yahoo.com> Received: from [210.76.108.109] by web15801.mail.cnb.yahoo.com via HTTP; Thu, 31 Mar 2005 09:49:35 CST Date: Thu, 31 Mar 2005 09:49:35 +0800 (CST) From: dfsd df Subject: Re: Some questions about kernel tailoring To: linux-mips@linux-mips.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tomcs163@yahoo.com.cn Precedence: bulk X-list: linux-mips Content-Length: 2725 Lines: 98 Thanks for your reply! > That's correct... 'vmlinux' is your kernel. mips > doesn't use zImages. But , the vmlinux is too big, Waht should I do? Is the vmlinux already compressed? > (PS... Please refrain from HTML email on this list) Sorry, I'm a newbie, I really don't know what you mean. :-) --- Stuart Longland wrote: > dfsd df wrote: > > Hello, everybody: > > Now, I participate to porting linux to MIPS > platform. I'm a newbie. > > > > I met some questions, I hope somebody can > tell me why or give me > > some hints! thanks! > > > > The board is Malta, CPU is MIPS4kc. I downloaded > kernel src from > > ftp.mips.com > > > > 1. I use "make zImage" for kernel-2.4.3, > everything is ok! > > But using "make zImage" for kernel-2.4.18, I > failed, It could only > > build a vmlinux file. > > That's correct... 'vmlinux' is your kernel. mips > doesn't use zImages. > > > I find it's because of no rules in > arch/mips/boot/Makefile to build > > zImage. > > So I modified the arch/mips/boot/Makefile, It > worked fine. > > but when excuted "./mkboot zImage.tmp zImage", It > generated a very big > > zImage file. After noticing "file size exceed", > the system delete the > > zImage file automatically! > > > > Try running mkboot on the vmlinux file. > > > what's wrong about it? It's ok for kernel-2.4.3. > and I can make sure > > that the mkboot is no problem. > > A newer kernel mightn't be a bad idea either... > 2.4.3 is very old now. > > > 2. I only selectd board and cpu type when > compiling the kernel-2.4.3. > > If using make ,the vmlinux size is about 780k. If > using "make zImage", > > the zImage file is about 580k. > > I think that's a minimun size by using "make > menuconfig". > > but I use gzip to compress this two files, its > size became only 1/3 of > > their original size. > > > > So I'm puzzled why "make zImage" don't use gzip > compress method? If so , > > we can get a more small kernel, isn't it? > > > > thanks again! > > I'll let the guru's chime in here :-) > > (PS... Please refrain from HTML email on this list) > > -- > +-------------------------------------------------------------+ > | Stuart Longland -oOo- > http://stuartl.longlandclan.hopto.org | > | Atomic Linux Project -oOo- > http://atomicl.berlios.de | > | - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - | > | I haven't lost my mind - it's backed up on a tape > somewhere | > +-------------------------------------------------------------+ > _________________________________________________________ Do You Yahoo!? ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ From stuartl@longlandclan.hopto.org Thu Mar 31 04:49:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 04:49:46 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:37128 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 04:49:30 +0100 Received: (qmail 1137 invoked by uid 210); 31 Mar 2005 13:49:20 +1000 Received: from 10.0.0.194 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.194):. Processed in 0.09421 secs); 31 Mar 2005 03:49:20 -0000 Received: from unknown (HELO ?10.0.0.194?) (10.0.0.194) by 192.168.5.1 with SMTP; 31 Mar 2005 13:49:19 +1000 Message-ID: <424B733B.3060307@longlandclan.hopto.org> Date: Thu, 31 Mar 2005 13:49:15 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dfsd df CC: linux-mips@linux-mips.org Subject: Re: Some questions about kernel tailoring References: <20050331014935.81645.qmail@web15801.mail.cnb.yahoo.com> In-Reply-To: <20050331014935.81645.qmail@web15801.mail.cnb.yahoo.com> X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB55D671CCC0CEC60146BF54" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Content-Length: 1957 Lines: 54 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB55D671CCC0CEC60146BF54 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit dfsd df wrote: > Thanks for your reply! > >>That's correct... 'vmlinux' is your kernel. mips >>doesn't use zImages. > > But , the vmlinux is too big, Waht should I do? Is the > vmlinux already compressed? Normally you manually gzip it -- but it will largely depend on what the bootloader for your device expects. Incidentally, are you trying to boot the kernel directly, or via something like U-boot or YAMON? AFAIK these evaluation boards are not designed to directly boot a kernel. >>(PS... Please refrain from HTML email on this list) > Sorry, I'm a newbie, I really don't know what you > mean. :-) Rich text emails -- in layman's terms. Couple of reasons for this: * They do make the email slightly larger * Not everyone can see HTML * SPAM and Viruses commonly exploit HTML Never mind though, as it seems your mail client has figured to use plaintext already. ;-) -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ --------------enigEB55D671CCC0CEC60146BF54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCS3NBuarJ1mMmSrkRApVUAJ4sxYFSDyuyWy/eqRswFeSPlb5LQwCeLZH+ n3/fwjuQ/0y9ttaMxhn1qFg= =zmIE -----END PGP SIGNATURE----- --------------enigEB55D671CCC0CEC60146BF54-- From jpfoster@exterity.co.uk Thu Mar 31 09:35:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 09:35:53 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:31512 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 09:35:38 +0100 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 09:37:07 +0100 Subject: Compressed Kernels From: JP Foster To: linux-mips Content-Type: text/plain Date: Thu, 31 Mar 2005 09:35:26 +0100 Message-Id: <1112258126.28438.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2005 08:37:07.0187 (UTC) FILETIME=[D28B4430:01C535CC] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jp.foster@exterity.co.uk Precedence: bulk X-list: linux-mips Content-Length: 409 Lines: 12 I've noticed that mips doesn't have a compressed kernel option, so I had added support (ripped shamelessly from arch/i386) for it to save space on our flash chips. It works fine for my db1550 and also our product boards. The patch is pretty messy but if there was interest in it I could clean it up. Is there any historical reason for it not being included? -- jp.foster@exterity.co.uk Digital Simplicity From robbat2@orbis-terrarum.net Thu Mar 31 09:42:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 09:42:25 +0100 (BST) Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:59128 "EHLO pd4mo2so.prod.shaw.ca") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 09:42:10 +0100 Received: from pd2mr7so.prod.shaw.ca (pd2mr7so-qfe3.prod.shaw.ca [10.0.141.10]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE700HH0K67GQHI@l-daemon> for linux-mips@linux-mips.org; Thu, 31 Mar 2005 01:42:07 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd2mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE700EMIK6750A0@pd2mr7so.prod.shaw.ca> for linux-mips@linux-mips.org; Thu, 31 Mar 2005 01:42:07 -0700 (MST) Received: from curie.orbis-terrarum.net (S01060050da688d47.vc.shawcable.net [24.80.100.253]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IE700B24K67Q6@l-daemon> for linux-mips@linux-mips.org; Thu, 31 Mar 2005 01:42:07 -0700 (MST) Received: (qmail 10008 invoked by uid 10000); Thu, 31 Mar 2005 00:42:07 -0800 Date: Thu, 31 Mar 2005 00:42:07 -0800 From: "Robin H. Johnson" Subject: Re: Compressed Kernels In-reply-to: <1112258126.28438.16.camel@localhost.localdomain> To: linux-mips Mail-followup-to: linux-mips Message-id: <20050331084207.GA8346@curie-int.orbis-terrarum.net> MIME-version: 1.0 Content-type: multipart/signed; boundary=C7zPtVaVf+AK4Oqc; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline References: <1112258126.28438.16.camel@localhost.localdomain> User-Agent: Mutt/1.5.6i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robbat2@orbis-terrarum.net Precedence: bulk X-list: linux-mips Content-Length: 1497 Lines: 47 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2005 at 09:35:26AM +0100, JP Foster wrote: > I've noticed that mips doesn't have a compressed kernel option, > so I had added support (ripped shamelessly from arch/i386) for it > to save space on our flash chips. >=20 > It works fine for my db1550 and also our product boards. > The patch is pretty messy but if there was interest in it I could clean > it up. Is there any historical reason for it not being included? Pete Popov was already working some zImage code. His link for it: ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov/2.6/zImage_2_6_10.pat= ch It worked for me in January on an XXS1500 device, but I haven't tried it on any newer kernel since then. I don't know the current status of it, or if it is going to go into the main codebase at all. --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFCS7ffPpIsIjIzwiwRAjrHAJ9jE5iWhVYTGnBaM4LHFZJEF6U06wCfVWrb NOVhnzkK2irvo/GC3c6OfQM= =1PQv -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From tomcs163@yahoo.com.cn Thu Mar 31 10:41:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 10:41:52 +0100 (BST) Received: from web15805.mail.cnb.yahoo.com ([IPv6:::ffff:202.165.102.85]:5462 "HELO web15805.mail.cnb.yahoo.com") by linux-mips.org with SMTP id ; Thu, 31 Mar 2005 10:41:29 +0100 Message-ID: <20050331094116.66254.qmail@web15805.mail.cnb.yahoo.com> Received: from [210.76.108.109] by web15805.mail.cnb.yahoo.com via HTTP; Thu, 31 Mar 2005 17:41:15 CST Date: Thu, 31 Mar 2005 17:41:15 +0800 (CST) From: dfsd df Subject: Re: Some questions about kernel tailoring To: linux-mips@linux-mips.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-611930826-1112262075=:64927" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tomcs163@yahoo.com.cn Precedence: bulk X-list: linux-mips Content-Length: 4449 Lines: 70 --0-611930826-1112262075=:64927 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Thanks again! Because of the limitation of memory, I don't want to use YAMON. Using gzip -9, I can get a kernel more small than the kernel made by "make zImage". So I want to write a very simple bootloader and make a self-decompressed kernel. But why everyone use "make zImage" instead of my method? That's what puzzles me? Stuart Longland wrote: dfsd df wrote: > Thanks for your reply! > >>That's correct... 'vmlinux' is your kernel. mips >>doesn't use zImages. > > But , the vmlinux is too big, Waht should I do? Is the > vmlinux already compressed? Normally you manually gzip it -- but it will largely depend on what the bootloader for your device expects. Incidentally, are you trying to boot the kernel directly, or via something like U-boot or YAMON? AFAIK these evaluation boards are not designed to directly boot a kernel. >>(PS... Please refrain from HTML email on this list) > Sorry, I'm a newbie, I really don't know what you > mean. :-) Rich text emails -- in layman's terms. Couple of reasons for this: * They do make the email slightly larger * Not everyone can see HTML * SPAM and Viruses commonly exploit HTML Never mind though, as it seems your mail client has figured to use plaintext already. ;-) -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ --------------------------------- Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ --0-611930826-1112262075=:64927 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
Thanks again!
 
Because of the limitation of memory, I don't want to use YAMON.
Using gzip -9, I can get a kernel more small than the kernel made by "make zImage".
So I want to write a very simple bootloader and make a self-decompressed kernel.
 
But why everyone use "make zImage" instead of my method? That's what puzzles me? 

Stuart Longland <stuartl@longlandclan.hopto.org> wrote:
dfsd df wrote:
> Thanks for your reply!
>
>>That's correct... 'vmlinux' is your kernel. mips
>>doesn't use zImages.
>
> But , the vmlinux is too big, Waht should I do? Is the
> vmlinux already compressed?

Normally you manually gzip it -- but it will largely depend on what the
bootloader for your device expects. Incidentally, are you trying to
boot the kernel directly, or via something like U-boot or YAMON?
AFAIK these evaluation boards are not designed to directly boot a kernel.

>>(PS... Please refrain from HTML email on this list)
> Sorry, I'm a newbie, I really don't know what you
> mean. :-)

Rich text emails -- in layman's terms. Couple of reasons for this:
* They do make the email slightly larger
* Not everyone can see HTML
* SPAM and Viruses commonly exploit HTML

Never mind though, as it seems your mail client has figured to use
plaintext already. ;-)

--
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project -oOo- http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+


Do You Yahoo!?
150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌÃ
ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ
1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ --0-611930826-1112262075=:64927-- From eckhardt@satorlaser.com Thu Mar 31 13:47:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 13:47:22 +0100 (BST) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.176]:41678 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 13:47:06 +0100 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DGz4i-00024D-00; Thu, 31 Mar 2005 14:47:04 +0200 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DGz4i-0001nY-00; Thu, 31 Mar 2005 14:47:04 +0200 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] unused and buggy macros Date: Thu, 31 Mar 2005 14:47:24 +0200 User-Agent: KMail/1.7.1 Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503311447.24961.eckhardt@satorlaser.com> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e35cee35a663f5c944b9750a965814ae Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Content-Length: 2732 Lines: 90 Hi! In db1x00/db1x00.h are two macros (mmc_card_inserted, mmc_power_on) that are not used and partially buggy. The 'bug' in them is that they use 0xAE000000 directly instead of BCSR_KSEG1_ADDR, possibly breaking db1550 which has its BCSRs at a different address. Another thing I stumbled across is the definitions of NAND_* in the same file. These are repeated in a few other board-specific headers, but always with the same values. The final NAND_TIMING is also only used once in drivers/mtd/nand/au1550nd.c. I don't know if that is intentional, but maybe someone that knows what's going on there could take a look at it. This patch removes only the mmc_* macros, I didn't touch the others. The patch is against the 2.6 sources, but I found that these macros also exist under 2.4.29 (not sure if this is from l-m.org or from kernel.org) and are unused there as well. cheers Uli --- Index: include/asm/mach-db1x00/db1x00.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/mach-db1x00/db1x00.h,v retrieving revision 1.7 diff -u -w -r1.7 db1x00.h --- include/asm/mach-db1x00/db1x00.h 15 Jan 2005 01:31:04 -0000 1.7 +++ include/asm/mach-db1x00/db1x00.h 31 Mar 2005 12:45:51 -0000 @@ -59,7 +59,6 @@ unsigned short reserved6; /*1C*/ unsigned short swreset; unsigned short reserved7; - } BCSR; @@ -134,50 +133,6 @@ #define SET_VCC_VPP(VCC, VPP, SLOT)\ ((((VCC)<<2) | ((VPP)<<0)) << ((SLOT)*8)) -/* SD controller macros */ -/* - * Detect card. - */ -#define mmc_card_inserted(_n_, _res_) \ - do { \ - BCSR * const bcsr = (BCSR *)0xAE000000; \ - unsigned long mmc_wp, board_specific; \ - if ((_n_)) { \ - mmc_wp = BCSR_BOARD_SD1_WP; \ - } else { \ - mmc_wp = BCSR_BOARD_SD0_WP; \ - } \ - board_specific = au_readl((unsigned long)(&bcsr->specific)); \ - if (!(board_specific & mmc_wp)) {/* low means card present */ \ - *(int *)(_res_) = 1; \ - } else { \ - *(int *)(_res_) = 0; \ - } \ - } while (0) - -/* - * Apply power to card slot(s). - */ -#define mmc_power_on(_n_) \ - do { \ - BCSR * const bcsr = (BCSR *)0xAE000000; \ - unsigned long mmc_pwr, mmc_wp, board_specific; \ - if ((_n_)) { \ - mmc_pwr = BCSR_BOARD_SD1_PWR; \ - mmc_wp = BCSR_BOARD_SD1_WP; \ - } else { \ - mmc_pwr = BCSR_BOARD_SD0_PWR; \ - mmc_wp = BCSR_BOARD_SD0_WP; \ - } \ - board_specific = au_readl((unsigned long)(&bcsr->specific)); \ - if (!(board_specific & mmc_wp)) {/* low means card present */ \ - board_specific |= mmc_pwr; \ - au_writel(board_specific, (int)(&bcsr->specific)); \ - au_sync(); \ - } \ - } while (0) - - /* NAND defines */ /* Timing values as described in databook, * ns value stripped of * lower 2 bits. From ralf@linux-mips.org Thu Mar 31 17:12:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 17:12:50 +0100 (BST) Received: from p3EE2B2E8.dip.t-dialin.net ([IPv6:::ffff:62.226.178.232]:49284 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 17:12:35 +0100 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2VG9j0R002517; Thu, 31 Mar 2005 17:09:45 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2VG9gfr002516; Thu, 31 Mar 2005 17:09:42 +0100 Date: Thu, 31 Mar 2005 17:09:42 +0100 From: Ralf Baechle DL5RB To: Stuart Longland Cc: dfsd df , linux-mips@linux-mips.org Subject: Re: Some questions about kernel tailoring Message-ID: <20050331160942.GI27952@linux-mips.org> References: <20050330073742.28983.qmail@web15807.mail.cnb.yahoo.com> <424B2621.20006@longlandclan.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424B2621.20006@longlandclan.hopto.org> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 231 Lines: 8 On Thu, Mar 31, 2005 at 08:20:17AM +1000, Stuart Longland wrote: > (PS... Please refrain from HTML email on this list) The list is configured to reject HTML email. But - the filter didn't detect this broken use of HTML. Ralf From ppopov@embeddedalley.com Thu Mar 31 17:24:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 17:25:01 +0100 (BST) Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:56994 "HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Thu, 31 Mar 2005 17:24:45 +0100 Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp007.bizmail.sc5.yahoo.com with SMTP; 31 Mar 2005 16:24:43 -0000 Message-ID: <424C2450.4030406@embeddedalley.com> Date: Thu, 31 Mar 2005 08:24:48 -0800 From: Pete Popov Reply-To: ppopov@embeddedalley.com Organization: Embedded Alley Solutions, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robin H. Johnson" CC: linux-mips Subject: Re: Compressed Kernels References: <1112258126.28438.16.camel@localhost.localdomain> <20050331084207.GA8346@curie-int.orbis-terrarum.net> In-Reply-To: <20050331084207.GA8346@curie-int.orbis-terrarum.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 1125 Lines: 28 Robin H. Johnson wrote: > On Thu, Mar 31, 2005 at 09:35:26AM +0100, JP Foster wrote: > >>I've noticed that mips doesn't have a compressed kernel option, >>so I had added support (ripped shamelessly from arch/i386) for it >>to save space on our flash chips. >> >>It works fine for my db1550 and also our product boards. >>The patch is pretty messy but if there was interest in it I could clean >>it up. Is there any historical reason for it not being included? > > Pete Popov was already working some zImage code. > > His link for it: > ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov/2.6/zImage_2_6_10.patch > > It worked for me in January on an XXS1500 device, but I haven't tried it > on any newer kernel since then. > > I don't know the current status of it, or if it is going to go into the > main codebase at all. Should be easy to update if if doesn't apply cleanly anymore. I think the complaint about that patch is that it duplicates some code from other architectures and a more common solution is needed. Since I don't have time to work on something more common, the patch remains stand alone. Pete From stuartl@longlandclan.hopto.org Thu Mar 31 23:06:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 31 Mar 2005 23:06:57 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:52258 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Thu, 31 Mar 2005 23:06:41 +0100 Received: (qmail 6050 invoked by uid 210); 1 Apr 2005 08:06:30 +1000 Received: from 10.0.0.194 by www (envelope-from , uid 201) with qmail-scanner-1.25st (spamassassin: 3.0.2. perlscan: 1.25st. Clear:RC:1(10.0.0.194):. Processed in 0.095803 secs); 31 Mar 2005 22:06:30 -0000 Received: from unknown (HELO ?10.0.0.194?) (10.0.0.194) by 192.168.5.1 with SMTP; 1 Apr 2005 08:06:29 +1000 Message-ID: <424C745F.6030204@longlandclan.hopto.org> Date: Fri, 01 Apr 2005 08:06:23 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dfsd df CC: linux-mips@linux-mips.org Subject: Re: Some questions about kernel tailoring References: <20050331094116.66254.qmail@web15805.mail.cnb.yahoo.com> In-Reply-To: <20050331094116.66254.qmail@web15805.mail.cnb.yahoo.com> X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA83943D8C5FD892853D2CCB" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 7556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Content-Length: 1912 Lines: 48 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEA83943D8C5FD892853D2CCB Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit dfsd df wrote: > Thanks again! BTW: Your mail client has just switched back to its fixation on HTML. Could you please have a close look at the settings and disable HTML mail composition? (at least for this email address/domain) > Because of the limitation of memory, I don't want to use YAMON. > Using gzip -9, I can get a kernel more small than the kernel made by > "make zImage". > So I want to write a very simple bootloader and make a self-decompressed > kernel. AFAIK the bootloader is only resident during the initial bootup, and is normally gone by the time userland kicks in. (Think about it -- what's the point in it sticking around, its job is done ;-) If you've got at least 8MB RAM you should be okay. (And lets face it -- Linux on 4MB *IS NOT PRETTY* -- Been there, done that) How much RAM are you working with? -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ --------------enigEA83943D8C5FD892853D2CCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTHRnuarJ1mMmSrkRAi0wAJ4jGdtolWtp9OlNyDjThvEh+Tre9QCeL9Bb s0CA4iVeozHsZcNMkuKH+ms= =pw8G -----END PGP SIGNATURE----- --------------enigEA83943D8C5FD892853D2CCB--