From Rishabh@soc-soft.com Tue Feb 1 05:28:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 05:28:26 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:1541 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 1 Feb 2005 05:28:06 +0000 Received: from mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Tue, 01 Feb 2005 10:59:30 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Problem with HIGHMEM implementation for 32 bit mips-el port X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 1 Feb 2005 10:59:29 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C49D06C@soc-mail.soc-soft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem with HIGHMEM implementation for 32 bit mips-el port Thread-Index: AcUHZ5+GqdPkBSu5Qheuw5ro5eKB9QAtJutw Sensitivity: Personal 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: 7099 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: 11746 Lines: 265 Hi all, I am attaching the bootlog of the system. There is no PCI device connected to the system. I am using MVL port for TX4925 Processor. I modified the kernel code such that there is no hole in the global mem_map page allocation, thus leading to no direct resolution of high-memory page struct address and the virtual address. Also there is a global variable "high_memory" which is initialized in mem_init()[arch/mips/mm/init.c : line no 288]. What is it used for? Also why highstart_pfn is reinitialized to highstart_pfn = (KSEG1- KSEG0)>> PAGE_SHIFT; high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); On my system high_memory is getting calculated to 84000000, wherein it should be the virtual address marking the start of ZONE_HIGHMEM(0xe0000000)? Isn't it? ____________________________________________________________________________ PMON> g Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 16kB 4-way, linesize 32 bytes. Linux version 2.4.20_mvl31-rbhma4300-mips_fp_le (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #117 Mon Jan 31 16:13:09 IST 2005 Can't analyze prologue code at 8003df5c TX4925 PCIC -- DID:0181 VID:102f RID:10 Arbiter:Internal TX4925 PCIC -- PCICLK:Determined physical RAM map: memory: 04000000 @ 00000000 (usable) memory: 04000000 @ 20000000 (usable) bootmem_init: map[0].start: 0, map[0].end: 4000 bootmem_init: map[1].start: 20000, map[1].end: 24000 bootmem_init: first_usable_pfn: 1de, max_low_pfn: 4000, highend_pfn: 24000 64MB HIGHMEM available. pgd: 801a1fe0, pmd: 801a1fe0, pte:801e0000, pkmap_page_table:801e0000 kmap_init: kmap_vstart: ffffe000, kmap_pte: 801dfff8, kmap_prot:2015 paging_init: low: 4000, max_dma: 1000, highstart_pfn: 20000, highend_pfn: 24000 On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 16384 pages. Zone Structure dump ZONE_DMA lock : 1 free_pages : 0 pages_min : 20 pages_low : 40 pages_high : 60 need_balance : 0 zone->free_area[0] : 801ac988 zone->free_area[1] : 801ac994 zone->free_area[2] : 801ac9a0 zone->free_area[3] : 801ac9ac zone->free_area[4] : 801ac9b8 zone->free_area[5] : 801ac9c4 zone->free_area[6] : 801ac9d0 zone->free_area[7] : 801ac9dc zone->free_area[8] : 801ac9e8 zone->free_area[9] : 801ac9f4 wait_table : 81180040 wait_table_size : 10 wait_table_shift : 1c zone_pgdat : 801ac974 zone_mem_map : 81000020 zone_start_paddr : 0 zone_start_mapnr : 0 name : 801497d0 size : 1000 ZONE_NORMAL lock : 1 free_pages : 0 pages_min : 60 pages_low : c0 pages_high : 120 need_balance : 0 zone->free_area[0] : 801aca38 zone->free_area[1] : 801aca44 zone->free_area[2] : 801aca50 zone->free_area[3] : 801aca5c zone->free_area[4] : 801aca68 zone->free_area[5] : 801aca74 zone->free_area[6] : 801aca80 zone->free_area[7] : 801aca8c zone->free_area[8] : 801aca98 zone->free_area[9] : 801acaa4 wait_table : 81180340 wait_table_size : 40 wait_table_shift : 1a zone_pgdat : 801ac974 zone_mem_map : 81030020 zone_start_paddr : 1000000 zone_start_mapnr : 1000 name : 801497d4 size : 3000 ZONE_HIGHMEM lock : 1 free_pages : 0 pages_min : 80 pages_low : 100 pages_high : 180 need_balance : 0 zone->free_area[0] : 801acae8 zone->free_area[1] : 801acaf4 zone->free_area[2] : 801acb00 zone->free_area[3] : 801acb0c zone->free_area[4] : 801acb18 zone->free_area[5] : 801acb24 zone->free_area[6] : 801acb30 zone->free_area[7] : 801acb3c zone->free_area[8] : 801acb48 zone->free_area[9] : 801acb54 wait_table : 81180ba0 wait_table_size : 40 wait_table_shift : 1a zone_pgdat : 801ac974 zone_mem_map : 810c0020 zone_start_paddr : 4000000 zone_start_mapnr : 4000 name : 801497dc size : 4000 Kernel command line: console=ttyS0,38400 ip=any ne_eth=0x17020280,27 root=/dev/ nfs rw Calibrating delay loop... 199.88 BogoMIPS MIPS CPU counter frequency is fixed at 100000000 Hz Memory: 127604k/65536k available (1301k kernel code, 3468k reserved, 92k data, 216k init, 65536k highmem) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Autoconfig PCI channel 0x801b6498 Scanning bus 00, I/O 0x00001000:0x01001000, Mem 0x08000000:0x10000000 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket LSP Revision 1 ikconfig 0.5 with /proc/ikconfig Starting kswapd Disabling the Out Of Memory Killer allocated 32 pages and 32 bhs reserved for the highmem bounces Dummy keyboard driver installed. pty: 256 Unix98 ptys configured TX39/49 Serial driver version 0.30-mvl ttyS0 at 0xff1ff300 (irq = 36) is a TX39/49 SIO ttyS1 at 0xff1ff400 (irq = 37) is a TX39/49 SIO ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com) Last modified Nov 1, 2000 by Paul Gortmaker NE*000 ethercard probe at 0x17020280: 00 60 0a 00 49 cf eth0: RBHMA4X00/RTL8019 found at 0x17020280, using IRQ 27. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 192.168.5.122, my address is 192.168.5.252 IP-Config: Complete: device=eth0, addr=192.168.5.252, mask=255.255.255.0, gw=255.255.255.255, host=192.168.5.252, domain=, nis-domain=(none), bootserver=192.168.5.122, rootserver=192.168.5.122, rootpath=/home/rishabh/ opt/montavista/pro/devkit/mips/fp_le/target NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. do_initcalls: call 8019d8ac Looking up port of RPC 100003/2 on 192.168.5.122 Looking up port of RPC 100005/1 on 192.168.5.122 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 216k freed PCI error interrupt (irq 0x35). pcistat:2290, g2pstatus:000001c0, pcicstatus:00000000 ccfg:18b44071 $0 : 00000000 10008401 00000000 00000000 0000002c 81189bb8 801b63ec 80141a90 $8 : 00000400 00000400 00000000 3fe946e3 0000fb10 00000000 0000fb10 00000000 $16: 801b63ec 00000001 81189bb8 0000002c 81189bb8 83cf3120 83ced0a0 00001000 $24: 00000000 801b91bf 81188000 81189b68 00000000 800213e4 Hi : 00000000 Lo : 00000000 epc : 800210ec Not tainted Status: 10008403 Cause : 00006c00 tx4925 pcic settings: 0000: 0181102f 22900146 06000010 00000000 00000008 00000008 00000000 00000001 0020: 00000000 00000000 00000000 00000000 00000000 000000dc 00000000 0000002c 0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0060: 00000090 000001c0 00000073 00000000 00000000 00000000 00000000 00000000 0080: 00000000 00000000 00002200 0000f900 00000000 00000018 00000000 00000000 00a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00220001 00e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0100: 76543210 00000002 00000000 00000000 00000000 00000000 00000080 00001801 0120: 08000000 00000000 00000000 00000000 00000000 00000000 04000000 00000000 0140: 07ffff00 00000000 00000000 00ffff00 08000000 00000000 00000000 00000000 0160: 00000000 00000000 00000000 00000000 000fff12 00000000 00000001 00000000 0180: 00000000 03f00206 00000000 00000000 00000000 00000000 00000000 00000000 Kernel panic: PCI error at PC:800210ec. In interrupt handler - not syncing <1>Unable to handle kernel paging request at virtual address 00000000, epc == 0 0000000, ra == 800d728c Oops in fault.c::do_page_fault, line 213: $0 : 00000000 10008401 00000000 bb020283 801b2c98 811898c0 00000000 00000000 $8 : 00000400 00000400 00002e9b 801b89b8 fffffffe ffffffff 00000010 00000007 $16: 00000000 83e54060 0000006e 801b2c98 00000001 801b2c98 17020280 00001000 $24: 8118997f ffffffff 81188000 811898a8 00000001 800d728c Hi : 00000000 Lo : 00000000 epc : 00000000 Not tainted Status: 10008403 Cause : 00000008 Process swapper (pid: 1, stackpage=81188000) Stack: ffffffff 0000000a 00000000 801b0000 ffffffff 0000000a 801b1c78 0000000c 00000000 00000001 00000000 17020283 17020287 801b89b8 00000001 17020280 83e54060 801b2c98 00000001 17020287 1702028d 00001000 00000000 800d6d64 40cd8ddc 81189988 80028a78 ffffffff 811853e0 00000001 81189988 0000001b 81189988 83cf3120 83ced0a0 80021104 8019e360 00000001 81189ab8 80141aa0 ... Call Trace: [<800d6d64>] [<80028a78>] [<80021104>] [<80141aa0>] [<800213e4>] [<80034158>] [<8015cccc>] [<80141cb4>] [<80034264>] [<8015cccc>] [<80033a18>] [<80033aa8>] [<801404ec>] [<800210ec>] [<80021104>] [<80141aa0>] [<800213e4>] [<80141cb4>] [<801310b8>] [<8012f634>] [<8013129c>] [<80141a90>] [<80039b40>] [<800213e4>] [<800210ec>] [<80141aa0>] [<800213e4>] [<80141cb4>] [<80091d88>] [<8004c6ac>] [<8013bc44>] [<8004c018>] [<8006b104>] [<8004c810>] [<8004c62c>] [<80091b78>] [<8006b01c>] [<80068bdc>] [<80069138>] [<800d0c34>] ... Code: (Bad address in epc) Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ____________________________________________________________________________ -----Original Message----- From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de] Sent: Monday, January 31, 2005 1:05 PM To: Rishabh Kumar Goel Cc: linux-mips@linux-mips.org Subject: Re: Problem with HIGHMEM implementation for 32 bit mips-el port On Mon, 2005-01-31 12:49:53 +0530, Rishabh@soc-soft.com wrote in message <4BF47D56A0DD2346A1B8D622C5C5902C472FE1@soc-mail.soc-soft.com>: > > Hi all, > > I am working on MIPS32 port of linux (kernel version 2.4.18) for R4000 > processor. While compilation was fine but the kernel boot up panics in > "init". 2.4.18? You opened some old sepulchre, didn't you? Please forward-port your patches at least to a recent 2.4.x kernel, if not 2.6.x. MfG, JBG -- 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ürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); 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 nsekhar@ti.com Tue Feb 1 09:36:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 09:36:51 +0000 (GMT) Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:9140 "EHLO go4.ext.ti.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 1 Feb 2005 09:36:35 +0000 Received: from dlep91.itg.ti.com ([157.170.152.55]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j119aXNs028229 for ; Tue, 1 Feb 2005 03:36:34 -0600 (CST) Received: from dbde2k01.ent.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id j119aTK6022461 for ; Tue, 1 Feb 2005 03:36:32 -0600 (CST) 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: Dealing with RAM not starting at 0x00000000 Date: Tue, 1 Feb 2005 15:06:29 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dealing with RAM not starting at 0x00000000 Thread-Index: AcUIQYDxSU+CaFtEQZGvJDQANn3N3w== From: "Nori, Soma Sekhar" 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: 7100 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: 448 Lines: 13 Hi All, I am working towards porting 2.6.10 kernel on a mips 4kec based board which has physical memory starting at 0x14000000. What is the best way to overcome the "hole" from 0x00000000 to 0x14000000 without incuring a huge memory overhead. (For exception handling there is 4k of RAM kept at 0x00000000 also - but I guess linux paging need need not be aware of this small RAM) Any suggestions/pointers are greatly appreciated. Thanks, Sekhar From andreev@niisi.msk.ru Tue Feb 1 13:46:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 13:46:48 +0000 (GMT) Received: from t111.niisi.ras.ru ([IPv6:::ffff:193.232.173.111]:42708 "EHLO t111.niisi.ras.ru") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 13:46:33 +0000 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.12.11/8.12.11) with ESMTP id j11DfP9w000976 for ; Tue, 1 Feb 2005 16:41:25 +0300 Received: from t06.niisi.ras.ru (localhost.localdomain [127.0.0.1]) by t06.niisi.ras.ru (8.12.8/8.12.8) with ESMTP id j11Dh8UN003442 for ; Tue, 1 Feb 2005 16:43:08 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.12.8/8.12.8/Submit) with UUCP id j11Dh7Sx003440 for linux-mips@linux-mips.org; Tue, 1 Feb 2005 16:43:07 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by aa19.niisi.msk.ru (8.12.8/8.12.8) with ESMTP id j11DjKkM017309 for ; Tue, 1 Feb 2005 16:45:21 +0300 Message-ID: <41FF876B.3070407@niisi.msk.ru> Date: Tue, 01 Feb 2005 16:43:07 +0300 From: andreev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Strace doesn't work on linux-2.4.28 and later Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: milter-spamc/0.13.216 (aa19 [172.16.0.19]); Tue, 01 Feb 2005 16:45:21 +0300 X-Antivirus: Dr.Web (R) for Mail Servers on t111.niisi.ras.ru host X-Antivirus-Code: 100000 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: 7101 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: andreev@niisi.msk.ru Precedence: bulk X-list: linux-mips Content-Length: 371 Lines: 13 Hi, list. We are using the latest kernel from mips-linux CVS and there is a problem with ptrace. When syscall with 5 or more arguments are traced, the fifth argument of the syscall is overwritten by tracing code. This error causes problems with strace. For example, you can't trace dynamically linked applications, because ld.so calls mmap which has 6 arguments. From mlachwani@prometheus.mvista.com Tue Feb 1 19:57:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 19:57:27 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29178 "EHLO prometheus.mvista.com") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 19:57:11 +0000 Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1]) by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id j11JvAdh005504; Tue, 1 Feb 2005 11:57:10 -0800 Received: (from mlachwani@localhost) by prometheus.mvista.com (8.12.8/8.12.8/Submit) id j11Jv9wK005502; Tue, 1 Feb 2005 11:57:09 -0800 Date: Tue, 1 Feb 2005 11:57:09 -0800 From: Manish Lachwani To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, mlachwani@mvista.com Subject: [PATCH] Fix compile errors for Sibyte Message-ID: <20050201195709.GA4206@prometheus.mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" 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: 7102 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: 883 Lines: 36 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ralf, With the latest CVS, when compiling for Sibyte: In file included from arch/mips/mm/cex-sb1.S:25: include/asm/sibyte/board.h:19:1: unterminated #ifndef make[1]: *** [arch/mips/mm/cex-sb1.o] Error 1 make: *** [arch/mips/mm] Error 2 Attached patch fixes it. Thanks Manish Lachwani --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="common_mips_sibyte_compile.patch" Index: linux/include/asm-mips/sibyte/board.h =================================================================== --- linux.orig/include/asm-mips/sibyte/board.h +++ linux/include/asm-mips/sibyte/board.h @@ -52,4 +52,6 @@ #define setleds(t0,t1,c0,c1,c2,c3) #endif /* LEDS_PHYS */ +#endif /* __ASSEMBLY__ */ + #endif /* _SIBYTE_BOARD_H */ --HcAYCG3uE/tztfnV-- From mlachwani@prometheus.mvista.com Tue Feb 1 20:28:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 20:28:52 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8183 "EHLO prometheus.mvista.com") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 20:28:36 +0000 Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1]) by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id j11KSZdh010813; Tue, 1 Feb 2005 12:28:35 -0800 Received: (from mlachwani@localhost) by prometheus.mvista.com (8.12.8/8.12.8/Submit) id j11KSZ1O010811; Tue, 1 Feb 2005 12:28:35 -0800 Date: Tue, 1 Feb 2005 12:28:35 -0800 From: Manish Lachwani To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix Kconfig for Broadcom SWARM Message-ID: <20050201202835.GA10788@prometheus.mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" 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: 7103 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: 733 Lines: 31 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ralf, Attached patch adds necessary options for Broadcom SWARM. Thanks Manish Lachwani --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="common_mips_sibyte_compile_1.patch" Index: linux/arch/mips/Kconfig =================================================================== --- linux.orig/arch/mips/Kconfig +++ linux/arch/mips/Kconfig @@ -498,6 +498,8 @@ select SWAP_IO_SPACE select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN + select SIBYTE_CFE + select SIBYTE_HAS_LDT config SIBYTE_SENTOSA bool "Support for Sibyte BCM91250E-Sentosa" --k+w/mQv8wyuph6w0-- From mlachwani@prometheus.mvista.com Tue Feb 1 21:26:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 21:26:20 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:5372 "EHLO prometheus.mvista.com") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 21:26:05 +0000 Received: from prometheus.mvista.com (localhost.localdomain [127.0.0.1]) by prometheus.mvista.com (8.12.8/8.12.8) with ESMTP id j11LQ3dh024821; Tue, 1 Feb 2005 13:26:03 -0800 Received: (from mlachwani@localhost) by prometheus.mvista.com (8.12.8/8.12.8/Submit) id j11LQ3rQ024819; Tue, 1 Feb 2005 13:26:03 -0800 Date: Tue, 1 Feb 2005 13:26:03 -0800 From: Manish Lachwani To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] read_can_lock and write_can_lock for MIPS Message-ID: <20050201212603.GA24787@prometheus.mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" 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: 7104 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: 841 Lines: 33 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ralf, With SMP+PREEMPT, read_can_lock() and write_can_lock() need to be defined. Attached patch does this. Please review. Thanks Manish Lachwani --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="common_mips_locks_preempt.patch" Index: linux/include/asm-mips/spinlock.h =================================================================== --- linux.orig/include/asm-mips/spinlock.h +++ linux/include/asm-mips/spinlock.h @@ -140,6 +140,9 @@ #define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0) +#define read_can_lock(rw) ((rw)->lock >= 0) +#define write_can_lock(rw) (!(rw)->lock) + static inline void _raw_read_lock(rwlock_t *rw) { unsigned int tmp; --6TrnltStXW4iwmi0-- From macro@linux-mips.org Tue Feb 1 22:42:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 22:42:38 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:7945 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 22:42:21 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 51F62E1CAA; Tue, 1 Feb 2005 23:42:08 +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 30837-05; Tue, 1 Feb 2005 23:42:08 +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 1FE97E1C6B; Tue, 1 Feb 2005 23:42:08 +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 j11MgD3P009717; Tue, 1 Feb 2005 23:42:13 +0100 Date: Tue, 1 Feb 2005 22:42:27 +0000 (GMT) From: "Maciej W. Rozycki" To: Manish Lachwani Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM In-Reply-To: <20050201202835.GA10788@prometheus.mvista.com> Message-ID: References: <20050201202835.GA10788@prometheus.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/661/Tue Jan 11 02:44:13 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: 7105 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: 144 Lines: 7 On Tue, 1 Feb 2005, Manish Lachwani wrote: > Attached patch adds necessary options for Broadcom SWARM. What is it supposed to do? Maciej From mlachwani@mvista.com Tue Feb 1 22:54:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 22:55:10 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60922 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 22:54:54 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 0812818963; Tue, 1 Feb 2005 14:54:51 -0800 (PST) Message-ID: <420008BA.6070104@mvista.com> Date: Tue, 01 Feb 2005 14:54:50 -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: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM References: <20050201202835.GA10788@prometheus.mvista.com> In-Reply-To: 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: 7106 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: 785 Lines: 33 Maciej W. Rozycki wrote: >On Tue, 1 Feb 2005, Manish Lachwani wrote: > > > >>Attached patch adds necessary options for Broadcom SWARM. >> >> > > What is it supposed to do? > > Maciej > > libs-$(CONFIG_SIBYTE_CFE) += arch/mips/sibyte/cfe/ in arch/mips/Makefile So, without the above, contents of arch/mips/sibyte/cfe/ are not compiled. SIBYTE_HAS_LDT is needed for the LDT specific stuff in arch/mips/pci/pci-sb1250.c Btw, there are other issues as well. More options need to be defined to compile in the serial driver, ethernet driver and to compile for a PASS 2 CPU. For example, the ethernet driver drivers/net/sb1250-mac.c compiles only if SIBYTE_SB1xxx_SOC is defined. And SIBYTE_SB1xxx_SOC no longer exists in arch/mips/Kconfig. Thanks Manish Lachwani From macro@linux-mips.org Tue Feb 1 23:26:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Feb 2005 23:27:15 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:23056 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 1 Feb 2005 23:26:59 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E1FD2E1CD3; Wed, 2 Feb 2005 00:26:51 +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 28240-08; Wed, 2 Feb 2005 00:26:51 +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 BE00EE1CA4; Wed, 2 Feb 2005 00:26:51 +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 j11NQvjl018162; Wed, 2 Feb 2005 00:26:57 +0100 Date: Tue, 1 Feb 2005 23:27:11 +0000 (GMT) From: "Maciej W. Rozycki" To: Manish Lachwani Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM In-Reply-To: <420008BA.6070104@mvista.com> Message-ID: References: <20050201202835.GA10788@prometheus.mvista.com> <420008BA.6070104@mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/661/Tue Jan 11 02:44:13 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: 7107 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: 832 Lines: 28 On Tue, 1 Feb 2005, Manish Lachwani wrote: > libs-$(CONFIG_SIBYTE_CFE) += arch/mips/sibyte/cfe/ > > in arch/mips/Makefile > > So, without the above, contents of arch/mips/sibyte/cfe/ are not compiled. > > SIBYTE_HAS_LDT is needed for the LDT specific stuff in > arch/mips/pci/pci-sb1250.c Both options are taken care of in arch/mips/sibyte/Kconfig, thus any fix should be sought there. > Btw, there are other issues as well. More options need to be defined to > compile in the serial driver, ethernet driver and to compile for a PASS 2 CPU. Likewise. > For example, the ethernet driver drivers/net/sb1250-mac.c compiles only if > SIBYTE_SB1xxx_SOC is defined. And SIBYTE_SB1xxx_SOC no longer exists in > arch/mips/Kconfig. This one is missing indeed. I'll have a look at how to get the mess resolved. Maciej From jgreen@users.sourceforge.net Wed Feb 2 00:35:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 00:35:50 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:2697 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 00:35:33 +0000 Received: from iria.infostations.net (iria.infostations.net [71.4.40.31]) by mail-relay.infostations.net (Postfix) with ESMTP id 16AD39F718 for ; Tue, 1 Feb 2005 16:35:53 -0800 (PST) Received: from host-69-19-171-174.rev.o1.com ([69.19.171.174]) by iria.infostations.net with esmtp (Exim 4.41 #1 (Gentoo)) id 1Cw8V2-0001yq-GN for ; Tue, 01 Feb 2005 16:36:06 -0800 Subject: Problems with PCMCIA on AMD Alchemy DB1100 From: Josh Green To: linux-mips@linux-mips.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-f8rVQ/0GO5hYvE2dZE4M" Date: Tue, 01 Feb 2005 16:36:07 -0800 Message-Id: <1107304567.2912.34.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: 7108 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 Content-Length: 6976 Lines: 183 --=-f8rVQ/0GO5hYvE2dZE4M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm using the latest Linux MIPS CVS (2.6.11-rc2) on an AMD Alchemy DB1100 with a tool chain created with buildroot (gcc 3.4.3, binutils 2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that was causing the following error during initialization (not exact text, close as I can remember), and subsequently the PCMCIA hardware was unavailable (pcmcia_register_socket() was failing due to NULL resource_opts field). au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22 Here is a patch: --- au1000_generic.c.orig 2005-02-01 12:19:29.572617936 -0800 +++ au1000_generic.c 2005-02-01 13:47:08.543132896 -0800 @@ -392,6 +392,7 @@ memset(skt, 0, sizeof(*skt)); skt->socket.ops =3D &au1x00_pcmcia_operations; + skt->socket.resource_ops =3D &pccard_static_ops; skt->socket.owner =3D ops->owner; skt->socket.dev.dev =3D dev; Additionally I noticed that some of the 36 bit constants in au1000_generic.h (AU1X_SOCK0_IO and AU1X_SOCK1_IO) were causing the warning "Integer constant too large for long type" (IIRC). Here is a patch for this, although I'm not sure if this is the correct way to fix it, or even if it was causing problems or not, although it does get rid of the warnings. --- au1000_generic.h.orig 2005-02-01 12:39:16.371197128 -0800 +++ au1000_generic.h 2005-02-01 12:40:23.405006440 -0800 @@ -34,9 +34,9 @@ #define AU1000_PCMCIA_IO_SPEED (255) #define AU1000_PCMCIA_MEM_SPEED (300) -#define AU1X_SOCK0_IO 0xF00000000 -#define AU1X_SOCK0_PHYS_ATTR 0xF40000000 -#define AU1X_SOCK0_PHYS_MEM 0xF80000000 +#define AU1X_SOCK0_IO 0xF00000000LL +#define AU1X_SOCK0_PHYS_ATTR 0xF40000000LL +#define AU1X_SOCK0_PHYS_MEM 0xF80000000LL /* pseudo 32 bit phys addresses, which get fixed up to the * real 36 bit address in fixup_bigphys_addr() */ #define AU1X_SOCK0_PSEUDO_PHYS_ATTR 0xF4000000 @@ -46,15 +46,15 @@ * differs from board to board. */ #if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_PB1100) || defined(= CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1550) -#define AU1X_SOCK1_IO 0xF08000000 -#define AU1X_SOCK1_PHYS_ATTR 0xF48000000 -#define AU1X_SOCK1_PHYS_MEM 0xF88000000 +#define AU1X_SOCK1_IO 0xF08000000LL +#define AU1X_SOCK1_PHYS_ATTR 0xF48000000LL +#define AU1X_SOCK1_PHYS_MEM 0xF88000000LL #define AU1X_SOCK1_PSEUDO_PHYS_ATTR 0xF4800000 #define AU1X_SOCK1_PSEUDO_PHYS_MEM 0xF8800000 #elif defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1100) || define= d(CONFIG_MIPS_DB1500) || defined(CONFIG_MIPS_DB1550) -#define AU1X_SOCK1_IO 0xF04000000 -#define AU1X_SOCK1_PHYS_ATTR 0xF44000000 -#define AU1X_SOCK1_PHYS_MEM 0xF84000000 +#define AU1X_SOCK1_IO 0xF04000000LL +#define AU1X_SOCK1_PHYS_ATTR 0xF44000000LL +#define AU1X_SOCK1_PHYS_MEM 0xF84000000LL #define AU1X_SOCK1_PSEUDO_PHYS_ATTR 0xF4400000 #define AU1X_SOCK1_PSEUDO_PHYS_MEM 0xF8400000 #endif Some additional problems that I have been experiencing, but am still investigating. If anyone has any ideas of what is causing these, I'd love to hear them. I have 2 Senao 802.11b PCMCIA cards and I'm using the hostap_cs driver. If I initialize pcmcia (cardmgr) with both cards in the PCMCIA slots only one of them will initialize, the second one causes an error: Linux Kernel Card Services options: none hostap_cs: 0.2.6 - 2004-12-25 (Jouni Malinen ) hostap_cs: Registered netdevice wifi0 hostap_cs: index 0x01: Vcc 3.3, irq 34, io 0xc0000000-0xc000003f wifi0: NIC: id=3D0x800c v1.0.0 wifi0: PRI: id=3D0x15 v1.1.0 wifi0: STA: id=3D0x1f v1.4.9 0.0: RequestIO: Configuration locked <--- Second card causes this 0.0: GetNextTuple: No more items ds: unable to create instance of 'hostap_cs'! If I bring up PCMCIA without the cards in, and then insert one, and then the other, both cards initialize fine and I get wlan0 and wlan1. The other problem I've experienced is a kernel oops when ejecting a card. While it isn't a problem for my project (should never be inserting/ejecting cards) I thought I'd mention it. Here is the oops output, I wasn't able to use ksymoops since I'm having trouble building a cross compiled version (buildroot didn't install libbfd, etc from binutils), so this may or may not be useful: Unhandled kernel unaligned access in arch/mips/kernel/unaligned.c::emulate_= load_store_insn, line 475[#1]: Cpu 0 $ 0 : 00000000 1000fc00 37312031 3a31303a $ 4 : 83e6cec8 1000fc01 80300d48 00000031 $ 8 : 8110e080 801fadcc 00000000 80318000 $12 : 00000001 00000000 00000003 00000000 $16 : c0010000 83e6cec0 812b77a0 00000008 $20 : 812b77d0 80223c38 00200200 00100100 $24 : 00000000 801f5c60 $28 : 83dea000 83debe88 80364b60 c000a860 Hi : 00000280 Lo : 00000230 epc : c000a8cc ds_event+0x2a0/0x4ac [pcmcia] Not tainted ra : c000a860 ds_event+0x234/0x4ac [pcmcia] Status: 1000fc02 KERNEL EXL Cause : 00800014 BadVA : 3a31303a PrId : 02030204 Modules linked in: hostap_cs hostap pcmcia au1x00_ss pcmcia_core Process pccardd (pid: 775, threadinfo=3D83dea000, task=3D83de67b0) Stack : c0007f18 8012c328 80364b60 c00137d8 802f0000 c0007efc c0007dcc 8010= 0dd8 0000003b c0007dcc c0007dcc c00052ec 80131c00 00200200 00000000 1000= fc01 c0007dcc 00000008 00000001 c00137d8 802f0000 c0007efc c0007f18 c000= 7f0c 802ebc88 c00138c4 00000001 00000000 00000003 00000000 c0007dcc 0000= 0000 c0013000 c0007dcc 80364b60 c0013d80 c0007f18 c0007f0c 00000000 2ab9= 2420 ... Call Trace: [<8012c328>] do_softirq+0x8c/0xb8 [] send_event+0x0/0x204 [pcmcia_core] [<80100dd8>] au1000_IRQ+0x118/0x1a0 [] au1x00_pcmcia_get_status+0x24/0x44 [au1x00_ss] [<80131c00>] msleep+0x48/0x60 [] send_event+0x0/0x204 [pcmcia_core] [<802ebc88>] __down+0x0/0x15c [] send_event+0xec/0x204 [pcmcia_core] [] cs_debug_level+0x0/0x10 [pcmcia_core] [] socket_shutdown+0x44/0x2cc [pcmcia_core] [] socket_remove+0x1c/0xf4 [pcmcia_core] [] pccardd+0x2fc/0x470 [pcmcia_core] [] pccardd+0x454/0x470 [pcmcia_core] [] pccardd+0x0/0x470 [pcmcia_core] [<801208f0>] default_wake_function+0x0/0x20 [<801208f0>] default_wake_function+0x0/0x20 [<80104e8c>] kernel_thread_helper+0x10/0x18 [<80104e7c>] kernel_thread_helper+0x0/0x18 Code: 8c820000 8c830004 2491fff8 ac430004 ac970000 ac960004 = 8e220020 34420010 Best regards, Josh Green --=-f8rVQ/0GO5hYvE2dZE4M 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) iD8DBQBCACB2RoMuWKCcbgQRAii7AJ9QgWk0UMO0+30AnARDG/2OXthTOgCcDIcM ysb51gr4w/AFXQmeS1UskrM= =6ak2 -----END PGP SIGNATURE----- --=-f8rVQ/0GO5hYvE2dZE4M-- From ppopov@embeddedalley.com Wed Feb 2 00:47:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 00:47:24 +0000 (GMT) Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:11688 "HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 2 Feb 2005 00:47:08 +0000 Received: from unknown (HELO ?10.2.2.64?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp002.bizmail.yahoo.com with SMTP; 2 Feb 2005 00:47:06 -0000 Message-ID: <4200230A.6020002@embeddedalley.com> Date: Tue, 01 Feb 2005 16:47:06 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Green CC: linux-mips@linux-mips.org Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 References: <1107304567.2912.34.camel@SillyPuddy.localdomain> In-Reply-To: <1107304567.2912.34.camel@SillyPuddy.localdomain> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7109 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: 2448 Lines: 58 Josh Green wrote: > I'm using the latest Linux MIPS CVS (2.6.11-rc2) on an AMD Alchemy > DB1100 with a tool chain created with buildroot (gcc 3.4.3, binutils > 2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that was > causing the following error during initialization (not exact text, close > as I can remember), and subsequently the PCMCIA hardware was unavailable > (pcmcia_register_socket() was failing due to NULL resource_opts field). > > au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22 Interesting. I haven't seen this problem with a slightly older kernel. > Additionally I noticed that some of the 36 bit constants in > au1000_generic.h (AU1X_SOCK0_IO and AU1X_SOCK1_IO) were causing the > warning "Integer constant too large for long type" (IIRC). Here is a > patch for this, although I'm not sure if this is the correct way to fix > it, or even if it was causing problems or not, although it does get rid > of the warnings. Thanks, will apply. > Some additional problems that I have been experiencing, but am still > investigating. If anyone has any ideas of what is causing these, I'd > love to hear them. > > I have 2 Senao 802.11b PCMCIA cards and I'm using the hostap_cs driver. > If I initialize pcmcia (cardmgr) with both cards in the PCMCIA slots > only one of them will initialize, the second one causes an error: > > Linux Kernel Card Services > options: none > hostap_cs: 0.2.6 - 2004-12-25 (Jouni Malinen ) > hostap_cs: Registered netdevice wifi0 > hostap_cs: index 0x01: Vcc 3.3, irq 34, io 0xc0000000-0xc000003f > wifi0: NIC: id=0x800c v1.0.0 > wifi0: PRI: id=0x15 v1.1.0 > wifi0: STA: id=0x1f v1.4.9 > 0.0: RequestIO: Configuration locked <--- Second card causes this > 0.0: GetNextTuple: No more items > ds: unable to create instance of 'hostap_cs'! > > > If I bring up PCMCIA without the cards in, and then insert one, and then > the other, both cards initialize fine and I get wlan0 and wlan1. No suggestions right now. > The other problem I've experienced is a kernel oops when ejecting a > card. While it isn't a problem for my project (should never be > inserting/ejecting cards) I thought I'd mention it. Here is the oops > output, I wasn't able to use ksymoops since I'm having trouble building > a cross compiled version (buildroot didn't install libbfd, etc from > binutils), so this may or may not be useful: I'll take a look at this. Pete From robbat2@orbis-terrarum.net Wed Feb 2 01:16:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 01:17:09 +0000 (GMT) Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:21829 "EHLO pd2mo3so.prod.shaw.ca") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 01:16:54 +0000 Received: from pd5mr5so.prod.shaw.ca (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IB9000J2FJIKTA0@l-daemon> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 18:16:30 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd5mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IB9007AZFJIHSE0@pd5mr5so.prod.shaw.ca> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 18:16:30 -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 <0IB900C0DFJHFA@l-daemon> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 18:16:30 -0700 (MST) Received: (qmail 17359 invoked by uid 10000); Tue, 01 Feb 2005 17:16:14 -0800 Date: Tue, 01 Feb 2005 17:16:14 -0800 From: "Robin H. Johnson" Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 In-reply-to: <1107304567.2912.34.camel@SillyPuddy.localdomain> To: linux-mips@linux-mips.org Mail-followup-to: linux-mips@linux-mips.org Message-id: <20050202011614.GA31554@curie-int.orbis-terrarum.net> MIME-version: 1.0 Content-type: multipart/signed; boundary=IJpNTDwzlM2Ie8A6; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline References: <1107304567.2912.34.camel@SillyPuddy.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: 7110 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: 2423 Lines: 59 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 04:36:07PM -0800, Josh Green wrote: > I'm using the latest Linux MIPS CVS (2.6.11-rc2) on an AMD Alchemy > DB1100 with a tool chain created with buildroot (gcc 3.4.3, binutils > 2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that > was causing the following error during initialization (not exact text, > close as I can remember), and subsequently the PCMCIA hardware was > unavailable (pcmcia_register_socket() was failing due to NULL > resource_opts field). >=20 > au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22 I can confirm this. I thought it was my error in trying to implement PCMCIA for the XXS1500 board. A fuller log available here: http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20050130.4.status The preliminary patch that status report refers to is: http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20050130.4.gz (not ready for any merging yet, still contains extra debug code) > The other problem I've experienced is a kernel oops when ejecting a > card. While it isn't a problem for my project (should never be > inserting/ejecting cards) I thought I'd mention it. Here is the oops > output, I wasn't able to use ksymoops since I'm having trouble > building a cross compiled version (buildroot didn't install libbfd, > etc from binutils), so this may or may not be useful: For your ksymoops, i find it very useful to build my host binutils (not the cross-compiler chain) with '--enable-targets=3Dall' as then it's possible to use your regular ksymoops (as of 2.4.10, see the INSTALL document for more details, I wrote up 'Building ksymoops for cross-debugging only' section ;-) without having to jump thru hoops for a cross-ksymoops. --=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 --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFCACnePpIsIjIzwiwRAqo1AJ9cDE2CBby7LgDk57tfNvGK2nJhTQCfTnB3 4Jdys48gxs2x99QXqhi+KUE= =0/jm -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From jgreen@users.sourceforge.net Wed Feb 2 05:49:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 05:50:09 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:50074 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 05:49:53 +0000 Received: from iria.infostations.net (iria.infostations.net [71.4.40.31]) by mail-relay.infostations.net (Postfix) with ESMTP id 0EC8C9F77E; Tue, 1 Feb 2005 21:50:12 -0800 (PST) Received: from host-69-19-168-166.rev.o1.com ([69.19.168.166]) by iria.infostations.net with esmtp (Exim 4.41 #1 (Gentoo)) id 1CwDPF-0006mh-QS; Tue, 01 Feb 2005 21:50:26 -0800 Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 From: Josh Green To: "Robin H. Johnson" Cc: linux-mips@linux-mips.org In-Reply-To: <20050202011614.GA31554@curie-int.orbis-terrarum.net> References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <20050202011614.GA31554@curie-int.orbis-terrarum.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SoQEV7hAIIjw4NVgkwlH" Date: Tue, 01 Feb 2005 21:50:35 -0800 Message-Id: <1107323435.15057.4.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: 7113 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 Content-Length: 1092 Lines: 37 --=-SoQEV7hAIIjw4NVgkwlH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 17:16 -0800, Robin H. Johnson wrote: > For your ksymoops, i find it very useful to build my host binutils (not > the cross-compiler chain) with '--enable-targets=3Dall' as then it's > possible to use your regular ksymoops (as of 2.4.10, see the INSTALL > document for more details, I wrote up 'Building ksymoops for > cross-debugging only' section ;-) without having to jump thru hoops for > a cross-ksymoops. >=20 Thanks for the tip on ksymoops, I'll give that a shot. I'm also using gentoo, for my host system, would be nice if there was a USE flag to enable all targets :) Cheers. Josh Green --=-SoQEV7hAIIjw4NVgkwlH 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) iD8DBQBCAGoqRoMuWKCcbgQRAp3YAKChpww4FTJVjKhXQA8JuhaXpe5KeACglNsx xCiJKkSppQaX3C/BKsX0Vsk= =rz6A -----END PGP SIGNATURE----- --=-SoQEV7hAIIjw4NVgkwlH-- From robbat2@orbis-terrarum.net Wed Feb 2 06:17:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 06:17:26 +0000 (GMT) Received: from shawidc-mo1.cg.shawcable.net ([IPv6:::ffff:24.71.223.10]:23893 "EHLO pd2mo3so.prod.shaw.ca") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 06:17:08 +0000 Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IB900JKQTF76X80@l-daemon> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 23:16:19 -0700 (MST) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IB90052XTF7S120@pd5mr7so.prod.shaw.ca> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 23:16:19 -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 <0IB90000ETF7FV@l-daemon> for linux-mips@linux-mips.org; Tue, 01 Feb 2005 23:16:19 -0700 (MST) Received: (qmail 29737 invoked by uid 10000); Tue, 01 Feb 2005 22:16:03 -0800 Date: Tue, 01 Feb 2005 22:16:03 -0800 From: "Robin H. Johnson" Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 In-reply-to: <1107323435.15057.4.camel@SillyPuddy.localdomain> To: linux-mips@linux-mips.org Cc: Josh Green Mail-followup-to: linux-mips@linux-mips.org, Josh Green Message-id: <20050202061603.GA21757@curie-int.orbis-terrarum.net> MIME-version: 1.0 Content-type: multipart/signed; boundary=HlL+5n6rz5pIUxbD; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <20050202011614.GA31554@curie-int.orbis-terrarum.net> <1107323435.15057.4.camel@SillyPuddy.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: 7114 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: 1393 Lines: 39 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 09:50:35PM -0800, Josh Green wrote: > > For your ksymoops, i find it very useful to build my host binutils (not > > the cross-compiler chain) with '--enable-targets=3Dall' as then it's > > possible to use your regular ksymoops (as of 2.4.10, see the INSTALL > > document for more details, I wrote up 'Building ksymoops for > > cross-debugging only' section ;-) without having to jump thru hoops for > > a cross-ksymoops. > Thanks for the tip on ksymoops, I'll give that a shot. I'm also using > gentoo, for my host system, would be nice if there was a USE flag to > enable all targets :) Cheers. stick 'multitarget' in your USE flags and re-merge binutils ;-). --=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 --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFCAHAjPpIsIjIzwiwRAkODAKDGVxjjxo47k5G6d2IPWHsbp3KKRACg7vvz MimdS6Yfl5udeWMj+co0Pk0= =b7At -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From jgreen@users.sourceforge.net Wed Feb 2 06:22:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 06:23:26 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:22428 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 06:22:58 +0000 Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35]) by mail-relay.infostations.net (Postfix) with ESMTP id 656229F7A4; Tue, 1 Feb 2005 22:23:18 -0800 (PST) Received: from host-69-19-168-166.rev.o1.com ([69.19.168.166]) by seriyu.infostations.net with esmtp (Exim 4.41 #1 (Gentoo)) id 1CwDqX-00080l-Tm; Tue, 01 Feb 2005 22:18:38 -0800 Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 From: Josh Green To: ppopov@embeddedalley.com Cc: linux-mips@linux-mips.org In-Reply-To: <4200230A.6020002@embeddedalley.com> References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <4200230A.6020002@embeddedalley.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Lb74te/O0h8S777a89OS" Date: Tue, 01 Feb 2005 22:23:44 -0800 Message-Id: <1107325424.15057.16.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: 7115 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 Content-Length: 3118 Lines: 93 --=-Lb74te/O0h8S777a89OS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-02-01 at 16:47 -0800, Pete Popov wrote: > Josh Green wrote: > > I'm using the latest Linux MIPS CVS (2.6.11-rc2) on an AMD Alchemy > > DB1100 with a tool chain created with buildroot (gcc 3.4.3, binutils > > 2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that wa= s > > causing the following error during initialization (not exact text, clos= e > > as I can remember), and subsequently the PCMCIA hardware was unavailabl= e > > (pcmcia_register_socket() was failing due to NULL resource_opts field). > >=20 > > au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22 >=20 > Interesting. I haven't seen this problem with a slightly older kernel. >=20 http://www.linux-mips.org/cvsweb/linux/drivers/pcmcia/cs.c.diff?r1=3D1.51&r= 2=3D1.52&f=3Dh The change around Line 212 looks like the reason. > Pete >=20 I'm still looking into those other problems. I found another issue though, which I'm unsure of the exact cause (seems related to hostap module). I get this from time to time: Badness in local_bh_enable at kernel/softirq.c:140 Call Trace: [<802482c4>] skb_clone+0x24/0x374 [<8012c3c8>] local_bh_enable+0x74/0x9c [<80251048>] dev_queue_xmit+0x310/0x374 [<80249884>] kfree_skbmem+0x14/0x30 [] hostap_data_start_xmit+0x80c/0xac4 [hostap] [<8024866c>] alloc_skb+0x58/0xf4 [<802a1240>] arp_constructor+0x28/0x274 [<802a0000>] udp_rcv+0x368/0x938 [<80250e14>] dev_queue_xmit+0xdc/0x374 [<80360000>] ip_auto_config_setup+0x64/0x240 [<802a2944>] arp_process+0x7f8/0xa6c [] hostap_80211_rx+0x1034/0x1f04 [hostap] [<80251978>] netif_receive_skb+0x1c4/0x3d4 [<80251978>] netif_receive_skb+0x1c4/0x3d4 [<80251c98>] process_backlog+0x110/0x2f0 [<80250000>] dev_change_name+0x34/0x2ec [] hostap_rx_tasklet+0x228/0x2bc [hostap_cs] [<80251f44>] net_rx_action+0xcc/0x294 [<8012c818>] tasklet_action+0xc4/0x194 [<801479f4>] handle_IRQ_event+0x7c/0x134 [<8012c1dc>] __do_softirq+0x8c/0x14c [<80147c40>] __do_IRQ+0x194/0x1b4 [<80360000>] ip_auto_config_setup+0x64/0x240 [<80360000>] ip_auto_config_setup+0x64/0x240 [<8012c328>] do_softirq+0x8c/0xb8 [<80360000>] ip_auto_config_setup+0x64/0x240 [<80100e2c>] au1000_IRQ+0x16c/0x1a0 [<80360000>] ip_auto_config_setup+0x64/0x240 [<80104a90>] cpu_idle+0x48/0x50 [<80104a60>] cpu_idle+0x18/0x50 [<801f4980>] idr_cache_ctor+0x0/0xc [<80360000>] ip_auto_config_setup+0x64/0x240 [<803437ac>] start_kernel+0x200/0x2c0 [<803430fc>] unknown_bootoption+0x0/0x310 Might not be a MIPS related problem though. Seems line 140 is "WARN_ON(irqs_disabled());" which is at the beginning of local_bh_enable. Cheers. Josh Green --=-Lb74te/O0h8S777a89OS 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) iD8DBQBCAHHuRoMuWKCcbgQRAjhuAKC5R4J5bvdBh0qmaZO15nuxKo/FAQCgvqlY UyX7kVbVniTbDMVjWjZbgTA= =rra8 -----END PGP SIGNATURE----- --=-Lb74te/O0h8S777a89OS-- From eckhardt@satorlaser.com Wed Feb 2 09:03:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 09:03:19 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.184]:14833 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 09:03:03 +0000 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CwGPe-0003FD-00; Wed, 02 Feb 2005 10:03:02 +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 1CwGPc-0007Mn-00; Wed, 02 Feb 2005 10:03:01 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: [PATCH] au1100fb.c ported from 2.4 to 2.6 Date: Wed, 2 Feb 2005 10:05:18 +0100 User-Agent: KMail/1.7.1 Cc: Christian References: <1105523407.5654.18.camel@absolute.ascensit.com> In-Reply-To: <1105523407.5654.18.camel@absolute.ascensit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502021005.18589.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: 7116 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: 607 Lines: 16 Christian wrote: > works in 16bpp, anyone with a system that works in 8bbp can give me a > hand to test this mode? I have a system that has a 4bpp monochrome display and the driver doesn't work. After initializing, it turns on the display[1] but I fail to get any content onto it. I extended the array with the display characteristics according to an existing driver, but to no avail. I'm pretty lost there, since I have zero prior experience with framebuffers or video drivers, so I'd appreciate any hint that might get me towards debugging this. Uli [1] p_lcd_reg->lcd_control |= LCD_CONTROL_GO; From jgreen@users.sourceforge.net Wed Feb 2 20:07:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 20:07:40 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:37568 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 20:07:23 +0000 Received: from kei.infostations.net (kei.infostations.net [71.4.40.33]) by mail-relay.infostations.net (Postfix) with ESMTP id 314B09F76C; Wed, 2 Feb 2005 12:07:42 -0800 (PST) Received: from host-66-81-128-82.rev.o1.com ([66.81.128.82]) by kei.infostations.net with esmtp (Exim 4.42 #1 (Gentoo)) id 1CwQny-0004p2-QZ; Wed, 02 Feb 2005 12:08:51 -0800 Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 From: Josh Green To: ppopov@embeddedalley.com Cc: linux-mips@linux-mips.org In-Reply-To: <4200230A.6020002@embeddedalley.com> References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <4200230A.6020002@embeddedalley.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RJrn6Hhzy6NmmgtLwks3" Date: Wed, 02 Feb 2005 12:07:48 -0800 Message-Id: <1107374868.15000.2.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: 7119 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 Content-Length: 2273 Lines: 67 --=-RJrn6Hhzy6NmmgtLwks3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > Some additional problems that I have been experiencing, but am still > > investigating. If anyone has any ideas of what is causing these, I'd > > love to hear them. > >=20 > > I have 2 Senao 802.11b PCMCIA cards and I'm using the hostap_cs driver. > > If I initialize pcmcia (cardmgr) with both cards in the PCMCIA slots > > only one of them will initialize, the second one causes an error: > >=20 > > Linux Kernel Card Services > > options: none > > hostap_cs: 0.2.6 - 2004-12-25 (Jouni Malinen ) > > hostap_cs: Registered netdevice wifi0 > > hostap_cs: index 0x01: Vcc 3.3, irq 34, io 0xc0000000-0xc000003f > > wifi0: NIC: id=3D0x800c v1.0.0 > > wifi0: PRI: id=3D0x15 v1.1.0 > > wifi0: STA: id=3D0x1f v1.4.9 > > 0.0: RequestIO: Configuration locked <--- Second card causes this > > 0.0: GetNextTuple: No more items > > ds: unable to create instance of 'hostap_cs'! > >=20 > >=20 > > If I bring up PCMCIA without the cards in, and then insert one, and the= n > > the other, both cards initialize fine and I get wlan0 and wlan1. >=20 I think I found this bug, and this time its in drivers/pcmcia/ds.c which surprises me, since I would think it would have been detected sooner. Here is the patch: --- ds.c.orig 2005-01-13 06:06:18.000000000 -0800 +++ ds.c 2005-02-02 11:58:29.125469160 -0800 @@ -660,7 +660,7 @@ p_dev =3D pcmcia_get_dev(p_dev); if (!p_dev) continue; - if ((!p_dev->client.state & CLIENT_UNBOUND) || + if ((!(p_dev->client.state & CLIENT_UNBOUND)) || (!p_dev->dev.driver)) { pcmcia_put_dev(p_dev); continue; Best regards, Josh Green --=-RJrn6Hhzy6NmmgtLwks3 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) iD8DBQBCATMURoMuWKCcbgQRAl3KAKCnwJ+AVF+m2XEvFHuy9MrRgPc4RACfTx+n Lk+0Uk2RWmKdZLBN9LB0/uU= =/J7U -----END PGP SIGNATURE----- --=-RJrn6Hhzy6NmmgtLwks3-- From jgreen@users.sourceforge.net Wed Feb 2 22:32:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 22:32:47 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:35786 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 22:32:31 +0000 Received: from iria.infostations.net (iria.infostations.net [71.4.40.31]) by mail-relay.infostations.net (Postfix) with ESMTP id 13CCE9F86C; Wed, 2 Feb 2005 14:32:50 -0800 (PST) Received: from host-69-19-150-206.rev.o1.com ([69.19.150.206]) by iria.infostations.net with esmtp (Exim 4.41 #1) id 1CwT3a-00086X-2j; Wed, 02 Feb 2005 14:33:06 -0800 Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 From: Josh Green To: ppopov@embeddedalley.com Cc: linux-mips@linux-mips.org In-Reply-To: <4200230A.6020002@embeddedalley.com> References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <4200230A.6020002@embeddedalley.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YJUinRZhDb8owL//gUVr" Date: Wed, 02 Feb 2005 14:33:17 -0800 Message-Id: <1107383597.21173.6.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: 7120 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 Content-Length: 1522 Lines: 48 --=-YJUinRZhDb8owL//gUVr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Seems the "Badness in local_bh_enable at kernel/softirq.c:140" error I reported has been fixed (patch that caused the problem was reverted in bk), here is a reference to this and a patch (had to replace " " with @ since they got munged by GMANE): http://article.gmane.org/gmane.linux.kernel/273477 On Tue, 2005-02-01 at 16:47 -0800, Pete Popov wrote: > > The other problem I've experienced is a kernel oops when ejecting a > > card. While it isn't a problem for my project (should never be > > inserting/ejecting cards) I thought I'd mention it. Here is the oops > > output, I wasn't able to use ksymoops since I'm having trouble building > > a cross compiled version (buildroot didn't install libbfd, etc from > > binutils), so this may or may not be useful: >=20 > I'll take a look at this. >=20 > Pete >=20 I tried ejecting a card and it seemed to work fine. The oops could have been related to the ds.c bug. At any rate, everything seems to be running great at this point and I have yet to see any other problems. Best regards, Josh Green --=-YJUinRZhDb8owL//gUVr 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) iD8DBQBCAVUrRoMuWKCcbgQRAsMiAJkBkZUVSSxsERLHwRh5CN1Fcx8nzwCfWKAc i5VGjKQ8h/bbVN9r/mmxHsk= =x/6V -----END PGP SIGNATURE----- --=-YJUinRZhDb8owL//gUVr-- From ppopov@embeddedalley.com Wed Feb 2 22:38:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 22:38:44 +0000 (GMT) Received: from mail.chipsandsystems.com ([IPv6:::ffff:64.164.196.27]:17384 "EHLO mail.chipsag.com") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 22:38:29 +0000 Received: from [10.1.100.35] ([10.1.100.35]) by mail.chipsag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Feb 2005 14:41:07 -0800 Message-ID: <42015662.2090605@embeddedalley.com> Date: Wed, 02 Feb 2005 14:38:26 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Green CC: linux-mips@linux-mips.org Subject: Re: Problems with PCMCIA on AMD Alchemy DB1100 References: <1107304567.2912.34.camel@SillyPuddy.localdomain> <4200230A.6020002@embeddedalley.com> <1107383597.21173.6.camel@SillyPuddy.localdomain> In-Reply-To: <1107383597.21173.6.camel@SillyPuddy.localdomain> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2005 22:41:07.0639 (UTC) FILETIME=[490F4470:01C50978] 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: 7121 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: 448 Lines: 11 > I tried ejecting a card and it seemed to work fine. The oops could have > been related to the ds.c bug. At any rate, everything seems to be > running great at this point and I have yet to see any other problems. Phew. I hadn't seen these problems and wasn't looking forward more pcmcia debug. I'll apply the other patches later. I can't apply the ds.c patch though -- that's out of my control. It should go to the pcmcia maintainer. Pete From nacc@us.ibm.com Wed Feb 2 23:09:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Feb 2005 23:09:18 +0000 (GMT) Received: from e3.ny.us.ibm.com ([IPv6:::ffff:32.97.182.143]:42699 "EHLO e3.ny.us.ibm.com") by linux-mips.org with ESMTP id ; Wed, 2 Feb 2005 23:09:01 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j12N8sZW005620; Wed, 2 Feb 2005 18:08:54 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12N8sGL127266; Wed, 2 Feb 2005 18:08:54 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j12N8snf004102; Wed, 2 Feb 2005 18:08:54 -0500 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j12N8sFv004065; Wed, 2 Feb 2005 18:08:54 -0500 Received: by joust (Postfix, from userid 1000) id 355F24F9C9; Wed, 2 Feb 2005 15:08:53 -0800 (PST) Date: Wed, 2 Feb 2005 15:08:53 -0800 From: Nishanth Aravamudan To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, kernel-janitors@lists.osdl.org Subject: [PATCH 20/20] mips/bcm1250_tbprof: remove interruptible_sleep_on() usage Message-ID: <20050202230853.GA2546@us.ibm.com> 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: 7122 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: nacc@us.ibm.com Precedence: bulk X-list: linux-mips Content-Length: 1569 Lines: 50 Hello, Please consider applying. Description: Remove deprecated interruptible_sleep_on() function call and replace with direct wait-queue usage. Signed-off-by: Nishanth Aravamudan --- 2.6.11-rc2-kj-v/arch/mips/sibyte/sb1250/bcm1250_tbprof.c 2005-01-24 09:28:12.000000000 -0800 +++ 2.6.11-rc2-kj/arch/mips/sibyte/sb1250/bcm1250_tbprof.c 2005-02-02 15:07:08.000000000 -0800 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -227,6 +228,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) { @@ -236,7 +238,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); @@ -344,7 +348,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 etienne@openfuel.com Thu Feb 3 08:38:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 08:39:01 +0000 (GMT) Received: from mail.cybersmart.co.za ([IPv6:::ffff:196.15.138.20]:4106 "EHLO optical.cyberhost.co.za") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 08:38:43 +0000 Received: from of0 (firewall.openfuel.com [196.15.138.55]) by optical.cyberhost.co.za (Postfix) with ESMTP id 16CE25B121 for ; Thu, 3 Feb 2005 10:38:43 +0200 (SAST) From: "Etienne Bauermeister" To: Subject: Kernel compile error - rtc.c Date: Thu, 3 Feb 2005 10:38:47 +0200 Message-ID: <000f01c509cb$c7420190$642aa8c0@of0> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C509DC.8ACAD190" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal 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: 7123 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: etienne@openfuel.com Precedence: bulk X-list: linux-mips Content-Length: 10595 Lines: 289 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C509DC.8ACAD190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am compiling the linux-2.6.11-rc2-mipscvs-20050130 kernel using a toolchain I built myself from instructions on this mailing list. The toolchain consists of binutils-2.13.90.0.10, glibc-2.2.5, glibc-linuxthreads-2.2.5 and gcc-3.2-7.1 from H.J. Lu with all the patches like glibc-2.2.5-mips-build-gmon etc. applied. I am compiling the kernel for the AMD Au1100 (big endian) on an i686 host. When I do this though I get the following error message a few minutes into the compilation process: CC drivers/char/rtc.o drivers/char/rtc.c: In function `rtc_init': drivers/char/rtc.c:955: `r' undeclared (first use in this function) drivers/char/rtc.c:955: (Each undeclared identifier is reported only once drivers/char/rtc.c:955: for each function it appears in.) make[2]: *** [drivers/char/rtc.o] Error 1 make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2 drivers/char/rtc.ot:~/mips/kernel/linux-2.6.11-rc2-mipscvs-20050130]$ I understand that the variable 'r' is not declared and this causes the error, but I don't know where to declare it or am I completely wrong and something else is at fault? Please provide some help with this. A second question relates to some warnings I got earlier in the compilation process stating that some 'variables' (I assume) are 'deprecated'. Is this anything to be concerned about? Thanks. Etienne Bauermeister Design Engineer OpenFuel (Pty) Ltd WWW: http://www.openfuel.com ------=_NextPart_000_0010_01C509DC.8ACAD190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I am compiling =
the linux-2.6.11-rc2-mipscvs-20050130 kernel using a toolchain I built myself from instructions on this =
mailing list. The toolchain consists of binutils-2.13.90.0.10, =
glibc-2.2.5, glibc-linuxthreads-2.2.5 and gcc-3.2-7.1 from H.J. Lu with =
all the patches like glibc-2.2.5-mips-build-gmon etc. applied. I am =
compiling the kernel for the AMD Au1100 (big endian) on an i686 host.  When I do this though I get the =
following error message a few minutes into the compilation =
process:
 
CC      =
drivers/char/rtc.o
drivers/char/rtc.c: In function `rtc_init':
drivers/char/rtc.c:955: `r' undeclared (first use in this =
function)
drivers/char/rtc.c:955: (Each undeclared identifier is reported =
only once
drivers/char/rtc.c:955: for each function it appears =
in.)
make[2]: *** =
[drivers/char/rtc.o] Error =
1
make[1]: *** =
[drivers/char] Error 2
make: *** [drivers] =
Error 2
drivers/char/rtc.ot:~/mips/kernel/linux-2.6.11-rc2-mipscvs-200501=
30]$
 
I understand =
that the variable ‘r’ is not declared and this causes the =
error, but I don’t know where to declare it or am I completely =
wrong and something else is at fault?  Please provide some help with =
this.  =

 
A second =
question relates to some warnings I got earlier in the compilation =
process stating that some ‘variables’ (I assume) are =
‘deprecated’.  =
Is this anything to be concerned =
about?
 
Thanks.
 

Etienne = Bauermeister

Design Engineer

OpenFuel (Pty) = Ltd

WWW: http://www.openfuel.com

 

 
------=_NextPart_000_0010_01C509DC.8ACAD190-- From eckhardt@satorlaser.com Thu Feb 3 09:22:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 09:22:23 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.191]:19444 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 09:22:08 +0000 Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CwdBd-0000SO-00 for linux-mips@linux-mips.org; Thu, 03 Feb 2005 10:22:05 +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 1CwdBd-00043N-00 for linux-mips@linux-mips.org; Thu, 03 Feb 2005 10:22:05 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: Kernel compile error - rtc.c Date: Thu, 3 Feb 2005 10:24:23 +0100 User-Agent: KMail/1.7.1 References: <000f01c509cb$c7420190$642aa8c0@of0> In-Reply-To: <000f01c509cb$c7420190$642aa8c0@of0> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031024.24321.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: 7124 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: 574 Lines: 19 Etienne Bauermeister wrote: > CC drivers/char/rtc.o > drivers/char/rtc.c: In function `rtc_init': > drivers/char/rtc.c:955: `r' undeclared (first use in this function) Just declare it at the top of the function, it was (accidentially) deleted during some recent cleanups. > A second question relates to some warnings I got earlier in the > compilation process stating that some 'variables' (I assume) are > 'deprecated'. Is this anything to be concerned about? Maybe. Impossible to say without more info. BTW: you're mailing plain text and HTML... cheers Uli From ralf@linux-mips.org Thu Feb 3 12:29:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 12:30:04 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:39794 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 12:29:50 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13CTmxN008642; Thu, 3 Feb 2005 13:29:48 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13CThwR008641; Thu, 3 Feb 2005 13:29:44 +0100 Date: Thu, 3 Feb 2005 13:29:43 +0100 From: Ralf Baechle To: "Nori, Soma Sekhar" Cc: linux-mips@linux-mips.org Subject: Re: Dealing with RAM not starting at 0x00000000 Message-ID: <20050203122943.GA8509@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: 7125 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: 648 Lines: 14 On Tue, Feb 01, 2005 at 03:06:29PM +0530, Nori, Soma Sekhar wrote: > I am working towards porting 2.6.10 kernel on a mips 4kec based board > which has physical memory starting at 0x14000000. > What is the best way to overcome the "hole" from 0x00000000 to > 0x14000000 without incuring a huge memory overhead. > (For exception handling there is 4k of RAM kept at 0x00000000 also - but > I guess linux paging need need not be aware of this small RAM) You can set PAGE_OFFSET to 0x94000000. If you do this you're probably going to run into a few bugs where PAGE_OFFSET is assumed to be KSEG0, that is 0x80000000. Nothing dramatic though. Ralf From ralf@linux-mips.org Thu Feb 3 12:37:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 12:37:44 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:46450 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 12:37:30 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13CbOhb008783; Thu, 3 Feb 2005 13:37:24 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13CbFEF008782; Thu, 3 Feb 2005 13:37:15 +0100 Date: Thu, 3 Feb 2005 13:37:15 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: Andrew Morton , linux-kernel , linux-mips Subject: Re: [PATCH 2.6.11-rc2-mm2] mips: iomap Message-ID: <20050203123715.GB8509@linux-mips.org> References: <20050131074618.09e65a6b.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050131074618.09e65a6b.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: 7126 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: 168 Lines: 7 On Mon, Jan 31, 2005 at 07:46:18AM +0900, Yoichi Yuasa wrote: > This patch adds iomap functions to MIPS system. And it still only works for a single PCI bus. Ralf From ralf@linux-mips.org Thu Feb 3 13:23:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 13:23:39 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:12915 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 13:23:25 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13DNN9O009520; Thu, 3 Feb 2005 14:23:23 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13DNGpa009519; Thu, 3 Feb 2005 14:23:16 +0100 Date: Thu, 3 Feb 2005 14:23:16 +0100 From: Ralf Baechle To: Etienne Bauermeister Cc: linux-mips@linux-mips.org Subject: Re: Kernel compile error - rtc.c Message-ID: <20050203132316.GC8509@linux-mips.org> References: <000f01c509cb$c7420190$642aa8c0@of0> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01c509cb$c7420190$642aa8c0@of0> 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: 7127 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: 943 Lines: 23 On Thu, Feb 03, 2005 at 10:38:47AM +0200, Etienne Bauermeister wrote: > CC drivers/char/rtc.o > drivers/char/rtc.c: In function `rtc_init': > drivers/char/rtc.c:955: `r' undeclared (first use in this function) > drivers/char/rtc.c:955: (Each undeclared identifier is reported only > once > drivers/char/rtc.c:955: for each function it appears in.) Know problem, sorry. > I understand that the variable 'r' is not declared and this causes the > error, but I don't know where to declare it or am I completely wrong and > something else is at fault? Please provide some help with this. > > A second question relates to some warnings I got earlier in the > compilation process stating that some 'variables' (I assume) are > 'deprecated'. Is this anything to be concerned about? It means it's team to update the code to use a newer API before the old, deprecated one is going to be removed. Remember, you've been warned :-) Ralf From ralf@linux-mips.org Thu Feb 3 13:30:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 13:30:16 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:18803 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 13:30:01 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13DU06q009644; Thu, 3 Feb 2005 14:30:00 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13DTu6s009643; Thu, 3 Feb 2005 14:29:56 +0100 Date: Thu, 3 Feb 2005 14:29:56 +0100 From: Ralf Baechle To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org Subject: Re: Kernel compile error - rtc.c Message-ID: <20050203132956.GD8509@linux-mips.org> References: <000f01c509cb$c7420190$642aa8c0@of0> <200502031024.24321.eckhardt@satorlaser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502031024.24321.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: 7128 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: 167 Lines: 7 On Thu, Feb 03, 2005 at 10:24:23AM +0100, Ulrich Eckhardt wrote: > BTW: you're mailing plain text and HTML... The list btw is setup to drop HTML-only email. Ralf From ralf@linux-mips.org Thu Feb 3 13:35:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 13:36:04 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:24435 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 13:35:50 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13DZnCV009773; Thu, 3 Feb 2005 14:35:49 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13DZi05009772; Thu, 3 Feb 2005 14:35:44 +0100 Date: Thu, 3 Feb 2005 14:35:44 +0100 From: Ralf Baechle To: Manish Lachwani Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] read_can_lock and write_can_lock for MIPS Message-ID: <20050203133544.GA9688@linux-mips.org> References: <20050201212603.GA24787@prometheus.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201212603.GA24787@prometheus.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: 7129 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: 302 Lines: 11 On Tue, Feb 01, 2005 at 01:26:03PM -0800, Manish Lachwani wrote: > Hi Ralf, > > With SMP+PREEMPT, read_can_lock() and write_can_lock() need to be defined. Attached > patch does this. Please review. Thanks, applied. In addition I copied the comments from the i386 code into the spinlocks.h. Ralf From ralf@linux-mips.org Thu Feb 3 13:38:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 13:38:34 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:26995 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 13:38:19 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13DcINs009830; Thu, 3 Feb 2005 14:38:18 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13DcDut009829; Thu, 3 Feb 2005 14:38:13 +0100 Date: Thu, 3 Feb 2005 14:38:13 +0100 From: Ralf Baechle To: Nishanth Aravamudan Cc: linux-mips@linux-mips.org, kernel-janitors@lists.osdl.org Subject: Re: [PATCH 20/20] mips/bcm1250_tbprof: remove interruptible_sleep_on() usage Message-ID: <20050203133813.GA9796@linux-mips.org> References: <20050202230853.GA2546@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202230853.GA2546@us.ibm.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: 7130 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: 234 Lines: 10 On Wed, Feb 02, 2005 at 03:08:53PM -0800, Nishanth Aravamudan wrote: > Please consider applying. > > Description: Remove deprecated interruptible_sleep_on() function call > and replace with direct wait-queue usage. Thanks, Ralf From ralf@linux-mips.org Thu Feb 3 14:29:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 14:29:35 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:116 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 14:29:20 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13ETJdf013751; Thu, 3 Feb 2005 15:29:19 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13ETJKu013750; Thu, 3 Feb 2005 15:29:19 +0100 Date: Thu, 3 Feb 2005 15:29:19 +0100 From: Ralf Baechle To: Manish Lachwani Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM Message-ID: <20050203142919.GB9796@linux-mips.org> References: <20050201202835.GA10788@prometheus.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201202835.GA10788@prometheus.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: 7131 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: 182 Lines: 7 On Tue, Feb 01, 2005 at 12:28:35PM -0800, Manish Lachwani wrote: > Attached patch adds necessary options for Broadcom SWARM. And forgets about all other Sibyte boards ... Ralf From ibrahim@schenk.isar.de Thu Feb 3 14:59:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 15:00:00 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:34319 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 14:59:44 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j13ExXH28681 for ; Thu, 3 Feb 2005 15:59:33 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j13ExXc11230 for ; Thu, 3 Feb 2005 15:59:33 +0100 Message-ID: <42023C54.7060801@schenk.isar.de> Date: Thu, 03 Feb 2005 15:59:32 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Titan ethernet and little endian X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------090909080801080709030600" 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: 7132 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 1289 Lines: 42 This is a multi-part message in MIME format. --------------090909080801080709030600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, a while ago I posted the attached patch, which makes the titan_ge driver work in little-endian mode. I got no reaction whatsoever. What did I do wrong? Rojhalat Ibrahim --------------090909080801080709030600 Content-Type: text/plain; name="titan_ge_little_endian_patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="titan_ge_little_endian_patch" Index: titan_ge.h =================================================================== RCS file: /home/cvs/linux/drivers/net/titan_ge.h,v retrieving revision 1.17 diff -u -r1.17 titan_ge.h --- titan_ge.h 4 Dec 2004 23:42:53 -0000 1.17 +++ titan_ge.h 10 Jan 2005 12:59:20 -0000 @@ -153,8 +153,10 @@ /* Define the Rx descriptor */ typedef struct eth_rx_desc { - u32 buffer_addr; /* Buffer address inclusive of checksum */ - u32 cmd_sts; /* Command and Status info */ + u32 buffer_addr; /* CPU buffer address */ + u32 reserved; /* Unused */ + u32 buffer; /* XDMA buffer address */ + u32 cmd_sts; /* Command and Status */ } titan_ge_rx_desc; /* Define the Tx descriptor */ --------------090909080801080709030600-- From macro@linux-mips.org Thu Feb 3 15:08:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 15:08:28 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:39953 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 15:08:12 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1EBACF5977; Thu, 3 Feb 2005 16:08:04 +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 09670-01; Thu, 3 Feb 2005 16:08:04 +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 BE695F5974; Thu, 3 Feb 2005 16:08:03 +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 j13F86d9004909; Thu, 3 Feb 2005 16:08:07 +0100 Date: Thu, 3 Feb 2005 15:08:15 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 20/20] mips/bcm1250_tbprof: remove interruptible_sleep_on() usage In-Reply-To: <20050203133813.GA9796@linux-mips.org> Message-ID: References: <20050202230853.GA2546@us.ibm.com> <20050203133813.GA9796@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/661/Tue Jan 11 02:44:13 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: 7133 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: 244 Lines: 10 On Thu, 3 Feb 2005, Ralf Baechle wrote: > > Description: Remove deprecated interruptible_sleep_on() function call > > and replace with direct wait-queue usage. > > Thanks, Except that should rather use wait_event_interruptible(). Maciej From ralf@linux-mips.org Thu Feb 3 15:35:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 15:35:36 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:54388 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 15:35:21 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13FZKwk014938; Thu, 3 Feb 2005 16:35:20 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13FZKja014937; Thu, 3 Feb 2005 16:35:20 +0100 Date: Thu, 3 Feb 2005 16:35:20 +0100 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050203153520.GF13804@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41ED20E3.60309@schenk.isar.de> 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: 7134 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: 470 Lines: 14 On Tue, Jan 18, 2005 at 03:44:51PM +0100, Rojhalat Ibrahim wrote: > is there anything special I have to do > when I want to use more than 512MB of memory? > My Yosemite board works fine with 512MB > but when I try 1GB it crashes in 32bit mode > with highmem and also in 64bit mode. > The boot monitor (PMON) maps the 1024MB > to physical addresses 0x0000.0000 - 0x4000.0000. Interesting. It's supposed to work but I don't have enough memory for testing this. Ralf From mlachwani@mvista.com Thu Feb 3 17:36:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 17:36:45 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33011 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 17:36:29 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 3BE8B18830; Thu, 3 Feb 2005 09:36:27 -0800 (PST) Message-ID: <4202611A.4000302@mvista.com> Date: Thu, 03 Feb 2005 09:36:26 -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: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM References: <20050201202835.GA10788@prometheus.mvista.com> <20050203142919.GB9796@linux-mips.org> In-Reply-To: <20050203142919.GB9796@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: 7135 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: 566 Lines: 29 Ralf Baechle wrote: >On Tue, Feb 01, 2005 at 12:28:35PM -0800, Manish Lachwani wrote: > > > >>Attached patch adds necessary options for Broadcom SWARM. >> >> > >And forgets about all other Sibyte boards ... > > Ralf > > The problem is that SIBYTE_SB1xxx_SOC is undefined. We need a small change in arch/mips/sibyte/Kconfig: config SIBYTE_SB1xxx_SOC bool "Support for Broadcom BCM1xxx SOCs " Since the ethernet driver, the serial driver and the CFE depend on this option to be selected else they wont be compiled in. Thanks Manish Lachwani From mlachwani@mvista.com Thu Feb 3 18:13:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 18:13:38 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:62197 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 18:13:22 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 561EA188B8; Thu, 3 Feb 2005 10:13:21 -0800 (PST) Message-ID: <420269C1.6050701@mvista.com> Date: Thu, 03 Feb 2005 10:13:21 -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: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: Titan ethernet and little endian References: <42023C54.7060801@schenk.isar.de> In-Reply-To: <42023C54.7060801@schenk.isar.de> 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: 7136 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: 1174 Lines: 44 Rojhalat Ibrahim wrote: > Hi, > a while ago I posted the attached patch, > which makes the titan_ge driver work in > little-endian mode. I got no reaction > whatsoever. What did I do wrong? > Rojhalat Ibrahim > >------------------------------------------------------------------------ > >Index: titan_ge.h >=================================================================== >RCS file: /home/cvs/linux/drivers/net/titan_ge.h,v >retrieving revision 1.17 >diff -u -r1.17 titan_ge.h >--- titan_ge.h 4 Dec 2004 23:42:53 -0000 1.17 >+++ titan_ge.h 10 Jan 2005 12:59:20 -0000 >@@ -153,8 +153,10 @@ > > /* Define the Rx descriptor */ > typedef struct eth_rx_desc { >- u32 buffer_addr; /* Buffer address inclusive of checksum */ >- u32 cmd_sts; /* Command and Status info */ >+ u32 buffer_addr; /* CPU buffer address */ >+ u32 reserved; /* Unused */ >+ u32 buffer; /* XDMA buffer address */ >+ u32 cmd_sts; /* Command and Status */ > } titan_ge_rx_desc; > > /* Define the Tx descriptor */ > > Hi ! So, have you got the titan to work in the LE mode? Are you using the Yosemite board? Does this patch break BE? Please do let us know. Thanks Manish Lachwani From mlachwani@mvista.com Thu Feb 3 18:20:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 18:21:14 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:26105 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 18:20:58 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id DE985189C8; Thu, 3 Feb 2005 10:20:56 -0800 (PST) Message-ID: <42026B88.6050908@mvista.com> Date: Thu, 03 Feb 2005 10:20:56 -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: Rojhalat Ibrahim , linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050203153520.GF13804@linux-mips.org> In-Reply-To: <20050203153520.GF13804@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: 7137 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: 682 Lines: 30 Ralf Baechle wrote: >On Tue, Jan 18, 2005 at 03:44:51PM +0100, Rojhalat Ibrahim wrote: > > > >>is there anything special I have to do >>when I want to use more than 512MB of memory? >>My Yosemite board works fine with 512MB >>but when I try 1GB it crashes in 32bit mode >>with highmem and also in 64bit mode. >>The boot monitor (PMON) maps the 1024MB >>to physical addresses 0x0000.0000 - 0x4000.0000. >> >> > >Interesting. It's supposed to work but I don't have enough memory for >testing this. > > Ralf > > > IIRC, you had posted the kernel boot log in a message as well. Can you post it again? For both the HIGHMEM case and the 64-bit case. Thanks Manish Lachwani From guy.streeter@gmail.com Thu Feb 3 22:26:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 22:26:53 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.197]:833 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 22:26:37 +0000 Received: by rproxy.gmail.com with SMTP id 1so281451rny for ; Thu, 03 Feb 2005 14:26:34 -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=kGm4iJEh/FdRE2vedsT4LHCchyZwPU5VXWgcSrXqnhsry0YxIoehqU1PvjFcisPRgobeqOBGMiR9eAT5R4LXN/RAdsMBvCD+XRJADGhexjcoEbLasF0BDX81t58WmnxvDwwFUHW+6AGB0TmBMCapau8V6mjwkZ1THpV/cfGom7k= Received: by 10.38.206.45 with SMTP id d45mr29311rng; Thu, 03 Feb 2005 14:26:34 -0800 (PST) Received: by 10.38.179.2 with HTTP; Thu, 3 Feb 2005 14:26:34 -0800 (PST) Message-ID: <52dd17640502031426660c7196@mail.gmail.com> Date: Thu, 3 Feb 2005 16:26:34 -0600 From: Guy Streeter Reply-To: Guy Streeter To: linux-mips Subject: NR_IRQS and possible irq values on malta 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: 7138 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: guy.streeter@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 489 Lines: 14 In mips_pcibios_iack() the irq number is obtained like this: irq = GT_READ(GT_PCI0_IACK_OFS); irq &= 0xff; (for coreLV, but similarly for others). This value is used to index into an array of size NR_IRQS, which is set in mach-generic/irq.h to 128. I realize that when things work right, the value of irq isn't likely to get that big, but it seems to me it should be masked down to 127 or the NR_IRQS value should be larger. I have no opinion which is the right thing to do. --Guy From macro@linux-mips.org Thu Feb 3 22:44:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 22:45:14 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:59914 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 22:44:59 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8B364F597F; Thu, 3 Feb 2005 23:44:47 +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 02876-06; Thu, 3 Feb 2005 23:44:47 +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 45AB8F5979; Thu, 3 Feb 2005 23:44:47 +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 j13Miq6N030621; Thu, 3 Feb 2005 23:44:52 +0100 Date: Thu, 3 Feb 2005 22:45:06 +0000 (GMT) From: "Maciej W. Rozycki" To: Guy Streeter Cc: linux-mips Subject: Re: NR_IRQS and possible irq values on malta In-Reply-To: <52dd17640502031426660c7196@mail.gmail.com> Message-ID: References: <52dd17640502031426660c7196@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.80/661/Tue Jan 11 02:44:13 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: 7139 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: 711 Lines: 20 On Thu, 3 Feb 2005, Guy Streeter wrote: > In mips_pcibios_iack() the irq number is obtained like this: > > irq = GT_READ(GT_PCI0_IACK_OFS); > irq &= 0xff; > > (for coreLV, but similarly for others). This value is used to index > into an array of size NR_IRQS, which is set in mach-generic/irq.h to > 128. > I realize that when things work right, the value of irq isn't likely > to get that big, but it seems to me it should be masked down to 127 or > the NR_IRQS value should be larger. I have no opinion which is the > right thing to do. It looks like a problem in __do_IRQ() (in kernel/irq/handle.c) -- it should probably call "BUG_ON(irq >= NR_IRQS)". MIPS-specific code doesn't care. Maciej From ralf@linux-mips.org Thu Feb 3 23:57:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Feb 2005 23:57:19 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:18298 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 3 Feb 2005 23:57:04 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j13Nv2ak023286; Fri, 4 Feb 2005 00:57:02 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j13Nv2SZ023285; Fri, 4 Feb 2005 00:57:02 +0100 Date: Fri, 4 Feb 2005 00:57:02 +0100 From: Ralf Baechle To: Manish Lachwani Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix Kconfig for Broadcom SWARM Message-ID: <20050203235702.GA22311@linux-mips.org> References: <20050201202835.GA10788@prometheus.mvista.com> <20050203142919.GB9796@linux-mips.org> <4202611A.4000302@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4202611A.4000302@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: 7140 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: 14 On Thu, Feb 03, 2005 at 09:36:26AM -0800, Manish Lachwani wrote: > The problem is that SIBYTE_SB1xxx_SOC is undefined. We need a small > change in arch/mips/sibyte/Kconfig: > > config SIBYTE_SB1xxx_SOC > bool "Support for Broadcom BCM1xxx SOCs " > > Since the ethernet driver, the serial driver and the CFE depend on this > option to be selected else they wont be compiled in. The fix for this is already in CVS since a few hours. Ralf From yuasa@hh.iij4u.or.jp Fri Feb 4 00:00:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 00:01:08 +0000 (GMT) Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:27599 "EHLO mo00.iij4u.or.jp") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 00:00:52 +0000 Received: MO(mo00)id j1400nd4015120; Fri, 4 Feb 2005 09:00:49 +0900 (JST) Received: MDO(mdo00) id j1400mkZ013538; Fri, 4 Feb 2005 09:00:48 +0900 (JST) Received: 4UMRO00 id j1400k3q010539; Fri, 4 Feb 2005 09:00:47 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Fri, 4 Feb 2005 09:00:40 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6.11-rc2-mm2] mips: iomap Message-Id: <20050204090040.61ce25d2.yuasa@hh.iij4u.or.jp> In-Reply-To: <20050203123715.GB8509@linux-mips.org> References: <20050131074618.09e65a6b.yuasa@hh.iij4u.or.jp> <20050203123715.GB8509@linux-mips.org> X-Mailer: Sylpheed version 1.0.0 (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: 7141 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: 323 Lines: 15 Hi Ralf, On Thu, 3 Feb 2005 13:37:15 +0100 Ralf Baechle wrote: > On Mon, Jan 31, 2005 at 07:46:18AM +0900, Yoichi Yuasa wrote: > > > This patch adds iomap functions to MIPS system. > > And it still only works for a single PCI bus. Which boards are there a problem? ocelot-c and ocelot-g? Yoichi From ralf@linux-mips.org Fri Feb 4 00:01:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 00:01:50 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:23418 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 00:01:23 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j1401Mix023404; Fri, 4 Feb 2005 01:01:22 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j1401McS023403; Fri, 4 Feb 2005 01:01:22 +0100 Date: Fri, 4 Feb 2005 01:01:22 +0100 From: Ralf Baechle To: Manish Lachwani Cc: Rojhalat Ibrahim , linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050204000122.GB22311@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> <20050203153520.GF13804@linux-mips.org> <42026B88.6050908@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42026B88.6050908@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: 7142 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: 285 Lines: 8 On Thu, Feb 03, 2005 at 10:20:56AM -0800, Manish Lachwani wrote: > IIRC, you had posted the kernel boot log in a message as well. Can you > post it again? For both the HIGHMEM case and the 64-bit case. http://www.linux-mips.org/archives/linux-mips/2005-01/msg00145.html :-) Ralf From ralf@linux-mips.org Fri Feb 4 00:40:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 00:40:43 +0000 (GMT) Received: from p3EE07C05.dip.t-dialin.net ([IPv6:::ffff:62.224.124.5]:52346 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 00:40:29 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j140eSEP024065; Fri, 4 Feb 2005 01:40:28 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j140eSA6024064; Fri, 4 Feb 2005 01:40:28 +0100 Date: Fri, 4 Feb 2005 01:40:28 +0100 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050204004028.GC22311@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41ED20E3.60309@schenk.isar.de> 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: 7143 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: 874 Lines: 28 On Tue, Jan 18, 2005 at 03:44:51PM +0100, Rojhalat Ibrahim wrote: > is there anything special I have to do > when I want to use more than 512MB of memory? > My Yosemite board works fine with 512MB > but when I try 1GB it crashes in 32bit mode > with highmem and also in 64bit mode. > The boot monitor (PMON) maps the 1024MB > to physical addresses 0x0000.0000 - 0x4000.0000. Can you try below patch? Ralf --- linux/arch/mips/mm/c-r4k.c 2004-12-07 02:30:50.000000000 +0000 +++ linux/arch/mips/mm/c-r4k.c 2005-02-04 00:31:34.623814760 +0000 @@ -566,7 +566,10 @@ if (!cpu_has_ic_fills_f_dc) { unsigned long addr = (unsigned long) page_address(page); - r4k_blast_dcache_page(addr); + if (addr) + r4k_blast_dcache_page(addr); + else + r4k_blast_dcache(); if (!cpu_icache_snoops_remote_store) r4k_blast_scache_page(addr); ClearPageDcacheDirty(page); From anemo@mba.ocn.ne.jp Fri Feb 4 09:38:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 09:38:39 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:33306 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Fri, 4 Feb 2005 09:38:20 +0000 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 4 Feb 2005 09:38:18 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 1252A239E5B; Fri, 4 Feb 2005 18:38:14 +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 j149cDRm035923; Fri, 4 Feb 2005 18:38:13 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 04 Feb 2005 18:38:13 +0900 (JST) Message-Id: <20050204.183813.132760959.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: dcache aliasing problem on fork 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: 7144 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: 1174 Lines: 38 There is a dcache aliasing problem on preempt kernel (or SMP kernel, perhaps) when a multi-threaded program calls fork(). 1. Now there is a process containing two thread (T1 and T2). The thread T1 call fork(). dup_mmap() function called on T1 context. static inline int dup_mmap(struct mm_struct * mm, struct mm_struct * oldmm) { ... flush_cache_mm(current->mm); /* A */ ... (write-protect all Copy-On-Write pages) ... /* B */ flush_tlb_mm(current->mm); ... } 2. When preemption happens between A and B (or on SMP kernel), the thread T2 can run and modify data on COW pages without page fault (modified data will stay in cache). 3. Some time after fork() completed, the thread T2 may cause page fault by write-protect on COW pages . 4. Then data of the COW page will be copied to newly allocated physical page (copy_cow_page()). It reads data via kernel mapping. The kernel mapping can have different 'color' with user space mapping of the thread T2 (dcache aliasing). Therefore copy_cow_page() will copy stale data. Then the modified data in cache will be lost. How should we fix this problem? Any idea? --- Atsushi Nemoto From c.pellegrin@exadron.com Fri Feb 4 09:57:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 09:57:41 +0000 (GMT) Received: from host51-186.pool80204.interbusiness.it ([IPv6:::ffff:80.204.186.51]:52100 "EHLO gate.exadron.com") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 09:57:26 +0000 Received: from 10.0.10.57 ([10.0.10.57]) by gate.exadron.com (8.12.7/8.12.7) with ESMTP id j14AMEmm013726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Feb 2005 11:22:14 +0100 Subject: Re: [PATCH] au1100fb.c ported from 2.4 to 2.6 From: Christian To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org In-Reply-To: <200502021005.18589.eckhardt@satorlaser.com> References: <1105523407.5654.18.camel@absolute.ascensit.com> <200502021005.18589.eckhardt@satorlaser.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bwYZ8fSlFY6LK1RLT1Ji" Date: Fri, 04 Feb 2005 10:56:43 +0100 Message-Id: <1107511003.5266.11.camel@absolute.ascensit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-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: 7146 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: c.pellegrin@exadron.com Precedence: bulk X-list: linux-mips Content-Length: 1596 Lines: 49 --=-bwYZ8fSlFY6LK1RLT1Ji Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-02-02 at 10:05 +0100, Ulrich Eckhardt wrote: > I have a system that has a 4bpp monochrome display and the driver doesn't= =20 > work. After initializing, it turns on the display[1] but I fail to get an= y=20 > content onto it. I extended the array with the display characteristics=20 > according to an existing driver, but to no avail. >=20 > I'm pretty lost there, since I have zero prior experience with framebuffe= rs or=20 > video drivers, so I'd appreciate any hint that might get me towards debug= ging=20 > this. Hi, you actually have to do the following modification modifications.=20 First you have to modify the function au1100fb_setcolreg, add the switch case for 4bpp. Look in the Alchemy manual for the format of the palette in the 4 bpp case. Then look for my comment "TODO: 8bbp", put a switch and for pseudocolor like visual ... I think this is not even necessary. More important is that you change the monitor type. If you want I can send you privately a patch this weekend, but I just cannot assure it works, you have to test it and eventually contribute. --=20 Christian --=-bwYZ8fSlFY6LK1RLT1Ji 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) iD8DBQBCA0baq26xP1xKlLcRAhzgAJ9HYXQalxEHvp4GAAPX3N7pYw3iJQCeI+dA 42U2qo++vtiNk9Q5/VNI4f4= =Z/An -----END PGP SIGNATURE----- --=-bwYZ8fSlFY6LK1RLT1Ji-- From eckhardt@satorlaser.com Fri Feb 4 13:16:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 13:16:52 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:45267 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 13:16:29 +0000 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Cx3Jz-0004lR-00; Fri, 04 Feb 2005 14:16:27 +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 1Cx3Jz-0000Db-00; Fri, 04 Feb 2005 14:16:27 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: [PATCH] au1100fb.c ported from 2.4 to 2.6 Date: Fri, 4 Feb 2005 14:18:47 +0100 User-Agent: KMail/1.7.1 References: <1105523407.5654.18.camel@absolute.ascensit.com> <200502021005.18589.eckhardt@satorlaser.com> <1107511003.5266.11.camel@absolute.ascensit.com> In-Reply-To: <1107511003.5266.11.camel@absolute.ascensit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502041418.47589.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: 7148 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: 4464 Lines: 158 Christian wrote: > First you have to modify the function au1100fb_setcolreg, add the switch > case for 4bpp. Look in the Alchemy manual for the format of the palette > in the 4 bpp case. Then look for my comment "TODO: 8bbp", put a switch > and for pseudocolor like visual ... I think this is not even necessary. Thanks, will look. > More important is that you change the monitor type. Yep, finding working parameters without real knowledge of what the registers mean was the hardest part, but I have it working now. > If you want I can > send you privately a patch this weekend, but I just cannot assure it > works, you have to test it and eventually contribute. I'd appreciate that, thank you. Currently I'm facing a different problem though, look at this code and the bitmap it generates (4bpp): unsigned long* fb = my_fb_info->fb_virt_start; fb[0] = 0x0000000f; // *....... fb[40] = 0x000000f0; // .*...... fb[80] = 0x000000ff; // **...... fb[120] = 0xf0000f00; // ..*....* fb[160] = 0xff000f0f; // *.*...** fb[200] = 0xfff00ff0; // .**..*** fb[240] = 0xffff0fff; // ***.**** To me, expecting the LSB to be part of the leftmost pixel is not really surprising, but functions like cfb_fillrect() (or rather bitfill32() etc) expect the order to be the other way around. I'm afraid that other framebuffer functions also expect that, but I haven't gotten far enough to test those. I only tested cfb_fillrect() and, seeing it fail, started looking for answers... any idea? I stumbled across another .. err .. 'feature': take a look at the appended patch, in particular the handling of the mask for the first long, am I dreaming or is this in fact handled wrongly in the current FB code? I'm a bit confused, because the same mistake is made in pretty much every FB driver I looked at. Thanks Uli --- Index: cfbcopyarea.c =================================================================== RCS file: /home/cvs/linux/drivers/video/cfbcopyarea.c,v retrieving revision 1.10 diff -u -w -r1.10 cfbcopyarea.c --- cfbcopyarea.c 12 Oct 2004 01:45:47 -0000 1.10 +++ cfbcopyarea.c 4 Feb 2005 13:11:16 -0000 @@ -70,7 +70,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst); @@ -223,7 +223,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst); dst--; src--; Index: cfbfillrect.c =================================================================== RCS file: /home/cvs/linux/drivers/video/cfbfillrect.c,v retrieving revision 1.8 diff -u -w -r1.8 cfbfillrect.c --- cfbfillrect.c 12 Oct 2004 01:45:47 -0000 1.8 +++ cfbfillrect.c 4 Feb 2005 13:11:16 -0000 @@ -142,7 +142,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { FB_WRITEL(comp(val, FB_READL(dst), first), dst); dst++; n -= BITS_PER_LONG-dst_idx; @@ -166,7 +166,7 @@ // Trailing bits if (last) - FB_WRITEL(comp(val, FB_READL(dst), first), dst); + FB_WRITEL(comp(val, FB_READL(dst), last), dst); } } @@ -197,7 +197,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { FB_WRITEL(comp(pat, FB_READL(dst), first), dst); dst++; pat = pat << left | pat >> right; @@ -224,7 +224,7 @@ // Trailing bits if (last) - FB_WRITEL(comp(pat, FB_READL(dst), first), dst); + FB_WRITEL(comp(pat, FB_READL(dst), last), dst); } } @@ -252,7 +252,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { dat = FB_READL(dst); FB_WRITEL(comp(dat ^ val, dat, first), dst); dst++; @@ -287,7 +287,7 @@ // Trailing bits if (last) { dat = FB_READL(dst); - FB_WRITEL(comp(dat ^ val, dat, first), dst); + FB_WRITEL(comp(dat ^ val, dat, last), dst); } } } @@ -320,7 +320,7 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first != ~0UL) { dat = FB_READL(dst); FB_WRITEL(comp(dat ^ pat, dat, first), dst); dst++; @@ -354,7 +354,7 @@ // Trailing bits if (last) { dat = FB_READL(dst); - FB_WRITEL(comp(dat ^ pat, dat, first), dst); + FB_WRITEL(comp(dat ^ pat, dat, last), dst); } } } From anemo@mba.ocn.ne.jp Fri Feb 4 14:12:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 14:12:16 +0000 (GMT) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:62965 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Fri, 4 Feb 2005 14:12:00 +0000 Received: from localhost (p4027-ipad30funabasi.chiba.ocn.ne.jp [221.184.79.27]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 471908412; Fri, 4 Feb 2005 23:11:56 +0900 (JST) Date: Fri, 04 Feb 2005 23:12:54 +0900 (JST) Message-Id: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: c-r4k.c cleanup 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: 7149 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: 654 Lines: 23 This code is wrong (should be "c->dcache.waysize > PAGE_SIZE") and unnecessary (done correctly in probe_pcache). diff -u -r1.96 c-r4k.c --- arch/mips/mm/c-r4k.c 7 Dec 2004 02:33:02 -0000 1.96 +++ arch/mips/mm/c-r4k.c 4 Feb 2005 14:01:35 -0000 @@ -1213,9 +1213,6 @@ probe_pcache(); setup_scache(); - if (c->dcache.sets * c->dcache.ways > PAGE_SIZE) - c->dcache.flags |= MIPS_CACHE_ALIASES; - r4k_blast_dcache_page_setup(); r4k_blast_dcache_page_indexed_setup(); r4k_blast_dcache_setup(); Also, some MIPS32/MIPS64 chip have physically indexed data cache so do no suffer from aliasing. CPU_20KC is one of them. Others? --- Atsushi Nemoto From nigel@mips.com Fri Feb 4 14:39:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 14:39:44 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:62732 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 14:39:28 +0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1Cx4hR-0000SH-00; Fri, 04 Feb 2005 14:44:45 +0000 Received: from shoreditch-home.algor.co.uk ([172.20.192.99]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Cx4bz-0005IG-00; Fri, 04 Feb 2005 14:39:07 +0000 Message-ID: <4203890B.5030305@mips.com> Date: Fri, 04 Feb 2005 14:39:07 +0000 From: Nigel Stephens User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atsushi Nemoto CC: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: c-r4k.c cleanup References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> In-Reply-To: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.813, required 4, AWL, BAYES_00) 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: 7150 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: nigel@mips.com Precedence: bulk X-list: linux-mips Content-Length: 973 Lines: 33 Atsushi Nemoto wrote: >This code is wrong (should be "c->dcache.waysize > PAGE_SIZE") and >unnecessary (done correctly in probe_pcache). > >diff -u -r1.96 c-r4k.c >--- arch/mips/mm/c-r4k.c 7 Dec 2004 02:33:02 -0000 1.96 >+++ arch/mips/mm/c-r4k.c 4 Feb 2005 14:01:35 -0000 >@@ -1213,9 +1213,6 @@ > probe_pcache(); > setup_scache(); > >- if (c->dcache.sets * c->dcache.ways > PAGE_SIZE) >- c->dcache.flags |= MIPS_CACHE_ALIASES; >- > r4k_blast_dcache_page_setup(); > r4k_blast_dcache_page_indexed_setup(); > r4k_blast_dcache_setup(); > > >Also, some MIPS32/MIPS64 chip have physically indexed data cache so do >no suffer from aliasing. CPU_20KC is one of them. Others? > > The MIPS 24K family's caches are not physically indexed, but they do have optional h/w assist to prevent aliases in certain cache configurations. This optional feature is indicated by the read-only AR (alias removed) flag being set - that's bit 16 in the CP0 Config7 register. Nigel From ralf@linux-mips.org Fri Feb 4 14:58:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 14:58:20 +0000 (GMT) Received: from p3EE076D7.dip.t-dialin.net ([IPv6:::ffff:62.224.118.215]:39699 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 14:58:05 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j14Ew3lo005770; Fri, 4 Feb 2005 15:58:03 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j14Ew3i5005769; Fri, 4 Feb 2005 15:58:03 +0100 Date: Fri, 4 Feb 2005 15:58:03 +0100 From: Ralf Baechle To: Nigel Stephens Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050204145803.GA5618@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4203890B.5030305@mips.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: 7151 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: 554 Lines: 12 On Fri, Feb 04, 2005 at 02:39:07PM +0000, Nigel Stephens wrote: > The MIPS 24K family's caches are not physically indexed, but they do > have optional h/w assist to prevent aliases in certain cache > configurations. This optional feature is indicated by the read-only AR > (alias removed) flag being set - that's bit 16 in the CP0 Config7 register. That's not a new feature in the MIPS world; the R10000 family introduced that first and Linux knows how to make use of it. So now I just need to teach c-r4k.c to check the AR bit on the 24K. Ralf From dom@mips.com Fri Feb 4 15:20:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 15:20:21 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:4624 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 15:20:06 +0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1Cx5Kp-0001D8-00; Fri, 04 Feb 2005 15:25:27 +0000 Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Cx5FN-0005qe-00; Fri, 04 Feb 2005 15:19:49 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16899.37525.412441.558873@gargle.gargle.HOWL> Date: Fri, 4 Feb 2005 15:19:49 +0000 To: Ralf Baechle Cc: Nigel Stephens , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup In-Reply-To: <20050204145803.GA5618@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.845, required 4, AWL, BAYES_00) 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: 7152 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: dom@mips.com Precedence: bulk X-list: linux-mips Content-Length: 985 Lines: 24 Only some CPUs suffer from aliases. A 4Kbyte direct-mapped cache must be alias free, because all the virtual index bits are the same (being in-page) as the physical address bits. That's true but irrelvant, since there aren't any 4Kbyte caches: but what's slightly less obvious is that a 16Kbyte 4-way set-associative cache is also alias free. 24K's "AR" bit trick applies *only* to the D-cache, and only to a 32Kbyte cache. (But then most alias problems are D-cache aliases, and 32Kbyte happens to be the most popular size for a 24K cache - so this is a trick worth doing). Note that I-cache aliases are not completely harmless; sometimes you want to invalidate any I-cache copies of some data, and if it's aliased you may miss some of them. Shared libraries are generally aligned to some large page-size multiple - so multiple text images are usually the same colour, and don't matter. You can get problems with trampolines and stuff. -- Dominic Sweetman MIPS Technologies From ralf@linux-mips.org Fri Feb 4 15:45:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 15:45:48 +0000 (GMT) Received: from p3EE076D7.dip.t-dialin.net ([IPv6:::ffff:62.224.118.215]:5908 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 15:45:33 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j14FjW4n022596; Fri, 4 Feb 2005 16:45:32 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j14FjW91022595; Fri, 4 Feb 2005 16:45:32 +0100 Date: Fri, 4 Feb 2005 16:45:32 +0100 From: Ralf Baechle To: Dominic Sweetman Cc: Nigel Stephens , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050204154532.GA22217@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <16899.37525.412441.558873@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16899.37525.412441.558873@gargle.gargle.HOWL> 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: 7153 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: 1313 Lines: 30 On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote: > Only some CPUs suffer from aliases. A 4Kbyte direct-mapped cache must > be alias free, because all the virtual index bits are the same (being > in-page) as the physical address bits. That's true but irrelvant, > since there aren't any 4Kbyte caches: but what's slightly less obvious > is that a 16Kbyte 4-way set-associative cache is also alias free. I had dark memory of some el cheapo CPU having 4k caches. > 24K's "AR" bit trick applies *only* to the D-cache, and only to a > 32Kbyte cache. (But then most alias problems are D-cache aliases, and > 32Kbyte happens to be the most popular size for a 24K cache - so this > is a trick worth doing). > > Note that I-cache aliases are not completely harmless; sometimes you > want to invalidate any I-cache copies of some data, and if it's > aliased you may miss some of them. Shared libraries are generally > aligned to some large page-size multiple - so multiple text images are > usually the same colour, and don't matter. You can get problems with > trampolines and stuff. Linux computes the necessary alignment on the fly. The method used is not strictly correct because as you say it should account for possible I-cache aliases also. Seems it's cache day again today ;-) Ralf From ralf@linux-mips.org Fri Feb 4 15:53:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 15:53:57 +0000 (GMT) Received: from p3EE076D7.dip.t-dialin.net ([IPv6:::ffff:62.224.118.215]:15124 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 15:53:41 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j14Fre2b022764; Fri, 4 Feb 2005 16:53:40 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j14FreU8022763; Fri, 4 Feb 2005 16:53:40 +0100 Date: Fri, 4 Feb 2005 16:53:40 +0100 From: Ralf Baechle To: Dominic Sweetman Cc: Nigel Stephens , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050204155340.GB22217@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <16899.37525.412441.558873@gargle.gargle.HOWL> <20050204154532.GA22217@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204154532.GA22217@linux-mips.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: 7154 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: 1554 Lines: 46 On Fri, Feb 04, 2005 at 04:45:32PM +0100, Ralf Baechle wrote: > > Note that I-cache aliases are not completely harmless; sometimes you > > want to invalidate any I-cache copies of some data, and if it's > > aliased you may miss some of them. Shared libraries are generally > > aligned to some large page-size multiple - so multiple text images are > > usually the same colour, and don't matter. You can get problems with > > trampolines and stuff. > > Linux computes the necessary alignment on the fly. The method used is > not strictly correct because as you say it should account for possible > I-cache aliases also. > > Seems it's cache day again today ;-) This is what I've checked in. Ralf Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.97 diff -u -r1.97 c-r4k.c --- arch/mips/mm/c-r4k.c 4 Feb 2005 15:19:01 -0000 1.97 +++ arch/mips/mm/c-r4k.c 4 Feb 2005 15:48:38 -0000 @@ -1012,9 +1012,17 @@ * normally they'd suffer from aliases but magic in the hardware deals * with that for us so we don't need to take care ourselves. */ - if (c->cputype != CPU_R10000 && c->cputype != CPU_R12000) + switch (c->cputype) { if (c->dcache.waysize > PAGE_SIZE) - c->dcache.flags |= MIPS_CACHE_ALIASES; + + case CPU_R10000: + case CPU_R12000: + break; + case CPU_24K: + if (!(read_c0_config7() & (1 << 16))) + default: + c->dcache.flags |= MIPS_CACHE_ALIASES; + } switch (c->cputype) { case CPU_20KC: From jsun@junsun.net Fri Feb 4 17:44:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 17:44:42 +0000 (GMT) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:61656 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 17:44:25 +0000 Received: from gw.junsun.net (c-24-6-106-170.client.comcast.net[24.6.106.170]) by comcast.net (rwcrmhc13) with ESMTP id <20050204174413015009kfmie>; Fri, 4 Feb 2005 17:44:13 +0000 Received: from gw.junsun.net (gw.junsun.net [127.0.0.1]) by gw.junsun.net (8.13.1/8.13.1) with ESMTP id j14HiBb9000914; Fri, 4 Feb 2005 09:44:11 -0800 Received: (from jsun@localhost) by gw.junsun.net (8.13.1/8.13.1/Submit) id j14HiAuZ000913; Fri, 4 Feb 2005 09:44:10 -0800 Date: Fri, 4 Feb 2005 09:44:10 -0800 From: Jun Sun To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: dcache aliasing problem on fork Message-ID: <20050204174410.GC30430@gw.junsun.net> References: <20050204.183813.132760959.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204.183813.132760959.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: 7155 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: jsun@junsun.net Precedence: bulk X-list: linux-mips Content-Length: 1628 Lines: 48 On Fri, Feb 04, 2005 at 06:38:13PM +0900, Atsushi Nemoto wrote: > There is a dcache aliasing problem on preempt kernel (or SMP kernel, > perhaps) when a multi-threaded program calls fork(). > > 1. Now there is a process containing two thread (T1 and T2). The > thread T1 call fork(). dup_mmap() function called on T1 context. > > static inline int dup_mmap(struct mm_struct * mm, struct mm_struct * oldmm) > { > ... > flush_cache_mm(current->mm); > /* A */ > ... > (write-protect all Copy-On-Write pages) > ... > /* B */ > flush_tlb_mm(current->mm); > ... > } > > 2. When preemption happens between A and B (or on SMP kernel), the > thread T2 can run and modify data on COW pages without page fault > (modified data will stay in cache). > > 3. Some time after fork() completed, the thread T2 may cause page > fault by write-protect on COW pages . > > 4. Then data of the COW page will be copied to newly allocated > physical page (copy_cow_page()). It reads data via kernel mapping. > The kernel mapping can have different 'color' with user space > mapping of the thread T2 (dcache aliasing). Therefore > copy_cow_page() will copy stale data. Then the modified data in > cache will be lost. > > > How should we fix this problem? Any idea? > It seems to me a naive solution is to introduce a spinlock to make all three operation automic. you flush tlb first and make relavent tlb fault handling sync with this spinlock as well. At in theory it should fix the problem, but the spinlock might be held for too long this dup_mmap(). BTW, is this problem real or hypothetic? Jun From jsun@junsun.net Fri Feb 4 17:49:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 17:50:01 +0000 (GMT) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:44681 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 17:49:46 +0000 Received: from gw.junsun.net (c-24-6-106-170.client.comcast.net[24.6.106.170]) by comcast.net (rwcrmhc13) with ESMTP id <20050204174937015009n299e>; Fri, 4 Feb 2005 17:49:37 +0000 Received: from gw.junsun.net (gw.junsun.net [127.0.0.1]) by gw.junsun.net (8.13.1/8.13.1) with ESMTP id j14HnVkk000944; Fri, 4 Feb 2005 09:49:32 -0800 Received: (from jsun@localhost) by gw.junsun.net (8.13.1/8.13.1/Submit) id j14HnRYl000943; Fri, 4 Feb 2005 09:49:27 -0800 Date: Fri, 4 Feb 2005 09:49:27 -0800 From: Jun Sun To: Ralf Baechle Cc: Dominic Sweetman , Nigel Stephens , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050204174927.GD30430@gw.junsun.net> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <16899.37525.412441.558873@gargle.gargle.HOWL> <20050204154532.GA22217@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204154532.GA22217@linux-mips.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: 7156 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: jsun@junsun.net Precedence: bulk X-list: linux-mips Content-Length: 605 Lines: 15 On Fri, Feb 04, 2005 at 04:45:32PM +0100, Ralf Baechle wrote: > On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote: > > > Only some CPUs suffer from aliases. A 4Kbyte direct-mapped cache must > > be alias free, because all the virtual index bits are the same (being > > in-page) as the physical address bits. That's true but irrelvant, > > since there aren't any 4Kbyte caches: but what's slightly less obvious > > is that a 16Kbyte 4-way set-associative cache is also alias free. > > I had dark memory of some el cheapo CPU having 4k caches. > IDT (rc32332) has a 2K d-cache. :) Jun From ddaney@avtrex.com Fri Feb 4 17:51:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Feb 2005 17:52:15 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:15031 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Fri, 4 Feb 2005 17:51:59 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Feb 2005 09:51:55 -0800 Message-ID: <4203B636.6060606@avtrex.com> Date: Fri, 04 Feb 2005 09:51:50 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Dominic Sweetman , Nigel Stephens , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <16899.37525.412441.558873@gargle.gargle.HOWL> <20050204154532.GA22217@linux-mips.org> <20050204155340.GB22217@linux-mips.org> In-Reply-To: <20050204155340.GB22217@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2005 17:51:55.0443 (UTC) FILETIME=[372BC830:01C50AE2] 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: 7157 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: 1263 Lines: 43 Ralf Baechle wrote: > This is what I've checked in. > > Ralf > > Index: arch/mips/mm/c-r4k.c > =================================================================== > RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v > retrieving revision 1.97 > diff -u -r1.97 c-r4k.c > --- arch/mips/mm/c-r4k.c 4 Feb 2005 15:19:01 -0000 1.97 > +++ arch/mips/mm/c-r4k.c 4 Feb 2005 15:48:38 -0000 > @@ -1012,9 +1012,17 @@ > * normally they'd suffer from aliases but magic in the hardware deals > * with that for us so we don't need to take care ourselves. > */ > - if (c->cputype != CPU_R10000 && c->cputype != CPU_R12000) > + switch (c->cputype) { > if (c->dcache.waysize > PAGE_SIZE) > - c->dcache.flags |= MIPS_CACHE_ALIASES; > + > + case CPU_R10000: > + case CPU_R12000: > + break; > + case CPU_24K: > + if (!(read_c0_config7() & (1 << 16))) > + default: > + c->dcache.flags |= MIPS_CACHE_ALIASES; > + } > > switch (c->cputype) { > case CPU_20KC: That may be legal C, but I have a difficult time figuring out exactly what it is supposed to do as case labels in the middle of statements confuses me. Does the first if in the switch do anything? My reading of the spec indicates that it is unreachable code. Just my $0.02 David Daney. From anemo@mba.ocn.ne.jp Sat Feb 5 12:05:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 12:06:05 +0000 (GMT) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:26831 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Sat, 5 Feb 2005 12:05:50 +0000 Received: from localhost (p3087-ipad30funabasi.chiba.ocn.ne.jp [221.184.78.87]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 21416839F; Sat, 5 Feb 2005 21:05:47 +0900 (JST) Date: Sat, 05 Feb 2005 21:06:48 +0900 (JST) Message-Id: <20050205.210648.126573633.anemo@mba.ocn.ne.jp> To: jsun@junsun.net Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: dcache aliasing problem on fork From: Atsushi Nemoto In-Reply-To: <20050204174410.GC30430@gw.junsun.net> References: <20050204.183813.132760959.nemoto@toshiba-tops.co.jp> <20050204174410.GC30430@gw.junsun.net> 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: 7159 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: 864 Lines: 21 >>>>> On Fri, 4 Feb 2005 09:44:10 -0800, Jun Sun said: jsun> It seems to me a naive solution is to introduce a spinlock to jsun> make all three operation automic. you flush tlb first and make jsun> relavent tlb fault handling sync with this spinlock as well. jsun> At in theory it should fix the problem, but the spinlock might jsun> be held for too long this dup_mmap(). Yes, it may be too long. Also dup_mmap might sleep via alloc_pages, cond_resched_lock, etc. therefore the spinlock can not be held entirely. Now I think fixing copy_cow_page() might be a way to go. jsun> BTW, is this problem real or hypothetic? Yes. This is a real problem. Using fork() in multi-thread program should be legal and perhaps only way to call external program (system() will use fork() internally). It will not be a special case. --- Atsushi Nemoto From news@robertmichel.de Sat Feb 5 16:50:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 16:50:37 +0000 (GMT) Received: from ms-1.rz.RWTH-Aachen.DE ([IPv6:::ffff:134.130.3.130]:41471 "EHLO ms-dienst.rz.rwth-aachen.de") by linux-mips.org with ESMTP id ; Sat, 5 Feb 2005 16:50:21 +0000 Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IBG001JU6RW9H@ms-dienst.rz.rwth-aachen.de> for linux-mips@linux-mips.org; Sat, 05 Feb 2005 17:50:21 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 05 Feb 2005 17:50:20 +0100 (MET) Received: from robins (robins.karman5.RWTH-Aachen.DE [134.130.104.75]) by relay.rwth-aachen.de (8.13.0/8.13.0/1) with ESMTP id j15GoJ4e019387 for ; Sat, 05 Feb 2005 17:50:19 +0100 (MET) Received: from rob by robins with local (Exim 3.36 #1 (Debian)) id 1CxT8V-0001P4-00 for ; Sat, 05 Feb 2005 17:50:19 +0100 Date: Sat, 05 Feb 2005 17:50:19 +0100 From: Robert Michel Subject: patch like kexec for MIPS possible? To: linux-mips Message-id: <20050205165019.GC3071@mail.robertmichel.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.4i 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: 7160 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: news@robertmichel.de Precedence: bulk X-list: linux-mips Content-Length: 674 Lines: 22 Salve! Does the MIPS CPUs makes a patch like kexec possible? Kexec is a kernel patch which allows you to start another kernel. IMHO would such a kernel patch would be handy, especialy for small MIPS Linux boxes. For more info about kexec read e.g. http://www-106.ibm.com/developerworks/linux/library/l-kexec.html And please don't get me wrong - as a non-kernel-developer I'm very happy with your work - my question is not a request, I'm just interested if there is a limitation of the MIPS platform to do something like this or not. Greetings, rob PS: And _if_ it would be possible, maybe sombody read this and join thinking that this feature would be realy cool ;) From ica2_ts@csv.ica.uni-stuttgart.de Sat Feb 5 17:42:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 17:42:46 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:40018 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sat, 5 Feb 2005 17:42:31 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1CxTx1-0003ar-00 for ; Sat, 05 Feb 2005 18:42:31 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1CxTwM-0008K1-00; Sat, 05 Feb 2005 18:41:50 +0100 Date: Sat, 5 Feb 2005 18:41:50 +0100 To: Robert Michel Cc: linux-mips Subject: Re: patch like kexec for MIPS possible? Message-ID: <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> References: <20050205165019.GC3071@mail.robertmichel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205165019.GC3071@mail.robertmichel.de> 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: 7161 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: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Content-Length: 681 Lines: 20 Robert Michel wrote: > Salve! > > Does the MIPS CPUs makes a patch like kexec possible? > > Kexec is a kernel patch which allows you to start another kernel. MIPS kernels are usually position dependent code, and loaded in unmapped memory, so a kernel would need to overwrite itself for kexec. I don't know if kexec is flexible enough to handle this. > IMHO would such a kernel patch would be handy, especialy for > small MIPS Linux boxes. For more info about kexec read e.g. > http://www-106.ibm.com/developerworks/linux/library/l-kexec.html Frankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously? Thiemo From news@robertmichel.de Sat Feb 5 19:11:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 19:11:38 +0000 (GMT) Received: from ms-1.rz.RWTH-Aachen.DE ([IPv6:::ffff:134.130.3.130]:18090 "EHLO ms-dienst.rz.rwth-aachen.de") by linux-mips.org with ESMTP id ; Sat, 5 Feb 2005 19:11:14 +0000 Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IBG002CLDAORO@ms-dienst.rz.rwth-aachen.de> for linux-mips@linux-mips.org; Sat, 05 Feb 2005 20:11:13 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Sat, 05 Feb 2005 20:11:12 +0100 (MET) Received: from robins (robins.karman5.RWTH-Aachen.DE [134.130.104.75]) by relay.rwth-aachen.de (8.13.0/8.13.0/1) with ESMTP id j15JBBSe002712; Sat, 05 Feb 2005 20:11:11 +0100 (MET) Received: from rob by robins with local (Exim 3.36 #1 (Debian)) id 1CxVKo-0004aT-00; Sat, 05 Feb 2005 20:11:10 +0100 Date: Sat, 05 Feb 2005 20:11:10 +0100 From: Robert Michel Subject: Re: patch like kexec for MIPS possible? In-reply-to: <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> To: Thiemo Seufer Cc: linux-mips Message-id: <20050205191110.GD3071@mail.robertmichel.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20050205165019.GC3071@mail.robertmichel.de> <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.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: 7162 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: news@robertmichel.de Precedence: bulk X-list: linux-mips Content-Length: 2875 Lines: 84 Salve Thiemo! Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h: > MIPS kernels are usually position dependent code, and loaded in > unmapped memory, so a kernel would need to overwrite itself for > kexec. I don't know if kexec is flexible enough to handle this. Kexec is written for x86 (yet) - but the (my) question is if this would be possible with MIPS, too. --snip-- The magic of kexec One of the biggest challenges in the development of kexec comes from the fact that the Linux kernel runs from a fixed address in memory. This means that the new kernel needs to sit at the same place that the current kernel is running from. On x86 systems, the kernel sits at the physical address 0x100000 (virtual address 0xc0000000, known as PAGE_OFFSET). The task of overwriting the old kernel with the new one is done in three stages: 1. Copy the new kernel into memory. 2. Move this kernel image into dynamic kernel memory. 3. Copy this image into the real destination (overwriting the current kernel), and start the new kernel. --snap-- http://www-106.ibm.com/developerworks/library/l-kexec.html?ca=dnt-518 > > IMHO would such a kernel patch would be handy, especialy for > > small MIPS Linux boxes. For more info about kexec read e.g. > > http://www-106.ibm.com/developerworks/linux/library/l-kexec.html > > Frankly, I don't see what kexec is good for. Who else besides > kernel developers would need to reboot a machine continuously? Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS bootlaoders support USB-sticks or booting via VPNs? LinuxBios is a "nice" project, but for most boards/boxes Linuxer could be happy to be able to boot it - to develop a nice boadloader is depended from the hard/firmware of the systems. A kernel with a kexec like patch could be used into the bootchain for several reasons: - making developing and hacking more easy - booting with options - choice which kernel to boot - booting from original not supported devices (usb, network) - remote control for the boot process - bypassing memoryrestrictions of the bootloader - more flexibility - independance from proprietary bootloader - developing security, statistic features... - fail save boot - starting restore system, analyse tools.... - option for modular system - for upgrades lower downtimes (Router, Firewalls....) - perversive computing, the box could be on a place without physicaly access - the kernel would be more often updated, than the bootloader - just for fun - just because it could be usefull - an implemented feature may become the base for other features - unthinkable before this first step - ... So my point is not to boot a machine continuously, but to expand the bootchain: IMHO would be the most powerfull and flexible way to boot a linux kernel, to boot it just from an other linux kernel. ;) Greetings rob From sskowron@ET.PUT.Poznan.PL Sat Feb 5 19:58:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 19:58:23 +0000 (GMT) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:36745 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sat, 5 Feb 2005 19:58:07 +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 j15Jw6u18810 for ; Sat, 5 Feb 2005 20:58:06 +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 ) ; Sat, 5 Feb 2005 20:58:05 +0100 (MET) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j15JQ6601701 for ; Sat, 5 Feb 2005 20:26:06 +0100 (MET) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sat, 5 Feb 2005 20:26:04 +0100 (MET) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: Re: patch like kexec for MIPS possible? In-Reply-To: <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> 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: 7163 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: 291 Lines: 9 > Frankly, I don't see what kexec is good for. Who else besides > kernel developers would need to reboot a machine continuously? Yeah. And, speaking from experience, it is often caused by the hardware entering such an invalid state that requires a hard reset anyway. Stanislaw Skowronek From wd@denx.de Sat Feb 5 20:33:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Feb 2005 20:34:07 +0000 (GMT) Received: from mailout06.sul.t-online.com ([IPv6:::ffff:194.25.134.19]:17849 "EHLO mailout06.sul.t-online.com") by linux-mips.org with ESMTP id ; Sat, 5 Feb 2005 20:33:51 +0000 Received: from fwd06.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1CxWco-0000o3-00; Sat, 05 Feb 2005 21:33:50 +0100 Received: from denx.de (XRxHPiZXQeVbs0ia1-DSctoPgyZY1OMRzfBfhTeIrBl42VWI1iQa0L@[62.158.200.222]) by fmrl06.sul.t-online.com with esmtp id 1CxWcZ-0zYkpk0; Sat, 5 Feb 2005 21:33:35 +0100 Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id 463B942F9E; Sat, 5 Feb 2005 21:33:34 +0100 (MET) Received: by atlas.denx.de (Postfix, from userid 15) id CD4DBC108D; Sat, 5 Feb 2005 21:33:33 +0100 (MET) Received: from atlas.denx.de (localhost [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id CAC2A13D6DB; Sat, 5 Feb 2005 21:33:33 +0100 (MET) To: Robert Michel Cc: linux-mips From: Wolfgang Denk Subject: Re: patch like kexec for MIPS possible? Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Sat, 05 Feb 2005 20:11:10 +0100." <20050205191110.GD3071@mail.robertmichel.de> Date: Sat, 05 Feb 2005 21:33:28 +0100 Message-Id: <20050205203333.CD4DBC108D@atlas.denx.de> X-ID: XRxHPiZXQeVbs0ia1-DSctoPgyZY1OMRzfBfhTeIrBl42VWI1iQa0L@t-dialin.net X-TOI-MSGID: 50e230f1-10c5-4941-b350-ca80a19c5b8d 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: 7164 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: wd@denx.de Precedence: bulk X-list: linux-mips Content-Length: 1742 Lines: 48 In message <20050205191110.GD3071@mail.robertmichel.de> you wrote: > > Kexec is written for x86 (yet) - but the (my) question is if > this would be possible with MIPS, too. Other, smilar solutions exist for other architectures, like Magnus Damm's "relf" tool for PowerPC and x86 (relf - reload elf: a driver to load and start a new elf file from within Linux). Adaptions for other processors are more or less trivial. > Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS > bootlaoders support USB-sticks or booting via VPNs? Use U-Boot :-) > LinuxBios is a "nice" project, but for most boards/boxes Linuxer > could be happy to be able to boot it - to develop a nice boadloader > is depended from the hard/firmware of the systems. Use U-Boot :-) > A kernel with a kexec like patch could be used into the bootchain > for several reasons: ... > - booting from original not supported devices (usb, network) ... > - for upgrades lower downtimes (Router, Firewalls....) These are IMHO the only valid reasons for such an approach. > IMHO would be the most powerfull and flexible way > to boot a linux kernel, > to boot it just from an other linux kernel. We've been using "relf" in some projects (x86 - where we were stuck with really dumb BIOSes), but I cannot see many situations where kexec is actually better or more powerful than a decent bootloader line U-Boot. OK, I'm obviously biased. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de In an organization, each person rises to the level of his own incom- petency - The Peter Principle From ica2_ts@csv.ica.uni-stuttgart.de Sun Feb 6 00:28:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 00:28:27 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:23126 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 00:28:11 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1CxaHa-0006XM-00; Sun, 06 Feb 2005 01:28:10 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1CxaHZ-0000sK-00; Sun, 06 Feb 2005 01:28:09 +0100 Date: Sun, 6 Feb 2005 01:28:09 +0100 To: Robert Michel Cc: linux-mips Subject: Re: patch like kexec for MIPS possible? Message-ID: <20050206002809.GV28252@rembrandt.csv.ica.uni-stuttgart.de> References: <20050205165019.GC3071@mail.robertmichel.de> <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> <20050205191110.GD3071@mail.robertmichel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205191110.GD3071@mail.robertmichel.de> 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: 7166 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: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Content-Length: 2476 Lines: 85 Robert Michel wrote: > Salve Thiemo! > > Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h: > > MIPS kernels are usually position dependent code, and loaded in > > unmapped memory, so a kernel would need to overwrite itself for > > kexec. I don't know if kexec is flexible enough to handle this. [snip] > The task of overwriting the old kernel with the new one > is done in three stages: > > 1. Copy the new kernel into memory. > 2. Move this kernel image into dynamic kernel memory. > 3. Copy this image into the real destination (overwriting the current > kernel), and start the new kernel. Ok, so is no exception WRT. > > Frankly, I don't see what kexec is good for. Who else besides > > kernel developers would need to reboot a machine continuously? > > Does GRUB run on MIPS? No. > Does GRUB support SSH2? No idea. > Does most MIPS bootlaoders support USB-sticks or booting via VPNs? There are various, and usually they are open source, ao adding such features shouldn't be a problem. [snip] > - making developing and hacking more easy Usually done via netboot or JTAG download. > - booting with options > - choice which kernel to boot > - booting from original not supported devices (usb, network) > - remote control for the boot process > - bypassing memoryrestrictions of the bootloader > - more flexibility - independance from proprietary bootloader Those things should be fixed in the bootloader. > - developing security, statistic features... > - fail save boot > - starting restore system, analyse tools.... > - option for modular system ? > - for upgrades lower downtimes (Router, Firewalls....) 30 seconds for the tftp, and you have to hope the previous kernel left everything in a sane state. > - perversive computing, the box could be on a place without > physicaly access You don't want to do that without a safe fallback (aka serial console). > - the kernel would be more often updated, than the bootloader > - just for fun > - just because it could be usefull - an implemented feature > may become the base for other features - unthinkable before > this first step > - ... > > So my point is not to boot a machine continuously, > but to expand the bootchain: > > IMHO would be the most powerfull and flexible way > to boot a linux kernel, > to boot it just from an other linux kernel. > ;) What if any of both is buggy? Either you have a working fallback, or you'll be screwed sooner or later. Thiemo From dan@embeddededge.com Sun Feb 6 01:02:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 01:02:15 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:29445 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 01:02:00 +0000 Received: from [192.168.2.27] (h69-21-252-132.69-21.unk.tds.net [69.21.252.132]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j160gU4s014347; Sat, 5 Feb 2005 19:42:30 -0500 In-Reply-To: <20050205203333.CD4DBC108D@atlas.denx.de> References: <20050205203333.CD4DBC108D@atlas.denx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: linux-mips , Robert Michel From: Dan Malek Subject: Re: patch like kexec for MIPS possible? Date: Sat, 5 Feb 2005 20:01:46 -0500 To: Wolfgang Denk 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: 7167 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: 712 Lines: 21 On Feb 5, 2005, at 3:33 PM, Wolfgang Denk wrote: > ..... but I cannot see many situations where > kexec is actually better or more powerful than a decent bootloader > line U-Boot. OK, I'm obviously biased. I agree. I've played with booting kernels from kernels in both PowerPC and MIPS in the past, and the problem I always run into is drivers or kernel functions that assume a particular power up state. When rebooting from another kernel you don't have the same state as from power up, and some software doesn't like this. I suspect main reason for kexec is the horrible x86 bios and nothing that can be done about it. Oh, and I agree with your assessment, not that you are biased :-) -- Dan From wd@denx.de Sun Feb 6 09:29:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 09:29:46 +0000 (GMT) Received: from mailout03.sul.t-online.com ([IPv6:::ffff:194.25.134.81]:2232 "EHLO mailout03.sul.t-online.com") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 09:29:29 +0000 Received: from fwd10.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1CxijM-0004zW-02; Sun, 06 Feb 2005 10:29:24 +0100 Received: from denx.de (VauefuZcZe2LSVt6Ppheo+t0rS1Y142q6WcgyZwyYIVsXAUuch0Dgh@[62.158.200.195]) by fmrl10.sul.t-online.com with esmtp id 1CxijH-1hzWmu0; Sun, 6 Feb 2005 10:29:19 +0100 Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by denx.de (Postfix) with ESMTP id 04D6D42306; Sun, 6 Feb 2005 10:29:13 +0100 (MET) Received: by atlas.denx.de (Postfix, from userid 15) id 4537AC108D; Sun, 6 Feb 2005 10:29:05 +0100 (MET) Received: from atlas.denx.de (localhost [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id 42E6F13D6DB; Sun, 6 Feb 2005 10:29:05 +0100 (MET) To: Dan Malek Cc: linux-mips From: Wolfgang Denk Subject: Re: patch like kexec for MIPS possible? Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Sat, 05 Feb 2005 20:01:46 EST." Date: Sun, 06 Feb 2005 10:29:00 +0100 Message-Id: <20050206092905.4537AC108D@atlas.denx.de> X-ID: VauefuZcZe2LSVt6Ppheo+t0rS1Y142q6WcgyZwyYIVsXAUuch0Dgh@t-dialin.net X-TOI-MSGID: 4be76432-8cd3-40d0-b73f-1ddeaec6ff9b 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: 7168 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: wd@denx.de Precedence: bulk X-list: linux-mips Content-Length: 513 Lines: 17 In message you wrote: > > some software doesn't like this. I suspect main reason for > kexec is the horrible x86 bios and nothing that can be done > about it. Ummm.. some people got U-Boot running on x86 systems, too. But this is off topic here :-) Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Hindsight is an exact science. From ralf@linux-mips.org Sun Feb 6 16:01:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 16:01:55 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:16068 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 16:01:38 +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 j16Fun1c016069; Sun, 6 Feb 2005 15:56:50 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j16FunD8016068; Sun, 6 Feb 2005 15:56:49 GMT Date: Sun, 6 Feb 2005 15:56:49 +0000 From: Ralf Baechle To: Stanislaw Skowronek Cc: linux-mips@linux-mips.org Subject: Re: patch like kexec for MIPS possible? Message-ID: <20050206155649.GA11452@linux-mips.org> References: <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> 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: 7169 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: 572 Lines: 13 On Sat, Feb 05, 2005 at 08:26:04PM +0100, Stanislaw Skowronek wrote: > > Frankly, I don't see what kexec is good for. Who else besides > > kernel developers would need to reboot a machine continuously? > > Yeah. And, speaking from experience, it is often caused by the hardware > entering such an invalid state that requires a hard reset anyway. I guess only the big iron fraction among us will really be missing something like kexec - firmware reinitialization may take minutes on that calibre of system so being able to get around that would be a good thing. Ralf From sskowron@ET.PUT.Poznan.PL Sun Feb 6 16:11:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 16:12:11 +0000 (GMT) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:4574 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 16:11:56 +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 j16GBsu16938; Sun, 6 Feb 2005 17:11:55 +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 ) ; Sun, 6 Feb 2005 17:11:54 +0100 (MET) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j16GBrH20251; Sun, 6 Feb 2005 17:11:53 +0100 (MET) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sun, 6 Feb 2005 17:11:53 +0100 (MET) From: Stanislaw Skowronek To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: patch like kexec for MIPS possible? In-Reply-To: <20050206155649.GA11452@linux-mips.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: 7170 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: 583 Lines: 14 > > Yeah. And, speaking from experience, it is often caused by the hardware > > entering such an invalid state that requires a hard reset anyway. > I guess only the big iron fraction among us will really be missing > something like kexec - firmware reinitialization may take minutes on that > calibre of system so being able to get around that would be a good thing. Well, a firmware reinitialization on my Octane (the old one) takes minutes. Still, the kernel requires the hardware to be initalized by PROM (just like on Origins, really) so kexec is of no help here. Stanislaw From ralf@linux-mips.org Sun Feb 6 16:16:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 16:16:28 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:29380 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 16:16:14 +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 j16GBQR5016521; Sun, 6 Feb 2005 16:11:26 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j16GBQdi016520; Sun, 6 Feb 2005 16:11:26 GMT Date: Sun, 6 Feb 2005 16:11:26 +0000 From: Ralf Baechle To: Stanislaw Skowronek Cc: linux-mips@linux-mips.org Subject: Re: patch like kexec for MIPS possible? Message-ID: <20050206161126.GA16351@linux-mips.org> References: <20050206155649.GA11452@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: 7171 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: 737 Lines: 17 On Sun, Feb 06, 2005 at 05:11:53PM +0100, Stanislaw Skowronek wrote: > > I guess only the big iron fraction among us will really be missing > > something like kexec - firmware reinitialization may take minutes on that > > calibre of system so being able to get around that would be a good thing. > > Well, a firmware reinitialization on my Octane (the old one) takes > minutes. Still, the kernel requires the hardware to be initalized by PROM > (just like on Origins, really) so kexec is of no help here. That's something that could be dealt with. On Origins I usually disable memory test which helps a little but still is slower than I'd like. For general hacking eval boards that need like a second to reset just rock :-) Ralf From ralf@linux-mips.org Sun Feb 6 18:08:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 18:08:49 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:62917 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 18:08:33 +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 j16I3kTJ006791 for ; Sun, 6 Feb 2005 18:03:46 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j16I3kDh006790 for linux-mips@linux-mips.org; Sun, 6 Feb 2005 18:03:46 GMT Resent-Message-Id: <200502061803.j16I3kDh006790@dea.linux-mips.net> Received: from smtp3.pp.htv.fi ([IPv6:::ffff:213.243.153.36]:53642 "EHLO smtp3.pp.htv.fi") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 17:03:50 +0000 Received: from Unusual.Internal.Linux-SH.ORG (cs181080144.pp.htv.fi [82.181.80.144]) by smtp3.pp.htv.fi (Postfix) with ESMTP id 48BFB27AD65; Sun, 6 Feb 2005 19:03:48 +0200 (EET) Received: by Unusual.Internal.Linux-SH.ORG (Postfix, from userid 500) id 0B5F4BEE83; Sun, 6 Feb 2005 19:03:47 +0200 (EET) Date: Sun, 6 Feb 2005 19:03:47 +0200 From: Paul Mundt To: Sam Ravnborg Cc: Ralf Baechle , linux-kernel@vger.kernel.org Subject: [PATCH] Add as-option to top-level Makefile Message-ID: <20050206170347.GB27853@linux-sh.org> Mail-Followup-To: Paul Mundt , Sam Ravnborg , Ralf Baechle , linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline User-Agent: Mutt/1.5.6i Resent-From: ralf@linux-mips.org Resent-Date: Sun, 6 Feb 2005 18:03:46 +0000 Resent-To: 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: 7172 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: 2182 Lines: 66 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable cc-option can presently not be used for checking as flags. It seems like MIPS ran into this already and added their own as-option (which at this point seems to be completely unused on MIPS, so perhaps it's worth removing entirely from there). This patch moves the definition to the top-level Makefile so that others can make use of it (sh wants this with newer binutils that allow for ISA tuning, for instance). Additionally, it may make more sense to move the -Wa$(comma) stuff into as-option directly so it doesn't get repeated all over the place (though it seems unlikely that there will be enough users that actually care about this). =3D=3D=3D=3D=3D Makefile 1.563 vs edited =3D=3D=3D=3D=3D --- 1.563/Makefile 2005-02-03 03:50:51 +02:00 +++ edited/Makefile 2005-02-06 18:50:49 +02:00 @@ -279,6 +279,13 @@ # cc support functions to be used (only) in arch/$(ARCH)/Makefile # See documentation in Documentation/kbuild/makefiles.txt =20 +# as-option +# Usage: cflags-y +=3D $(call as-option, -Wa$(comma)-isa=3Dfoo,) + +as-option =3D $(shell if $(CC) $(CFLAGS) $(1) -Wa,-Z -c -o /dev/null \ + -xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; \ + else echo "$(2)"; fi ;) + # cc-option # Usage: cflags-y +=3D $(call gcc-option, -march=3Dwinchip-c6, -march=3Di5= 86) =20 =3D=3D=3D=3D=3D arch/mips/Makefile 1.28 vs edited =3D=3D=3D=3D=3D --- 1.28/arch/mips/Makefile 2005-01-31 08:33:43 +02:00 +++ edited/arch/mips/Makefile 2005-02-06 18:49:20 +02:00 @@ -12,10 +12,6 @@ # for "archclean" cleaning up for this architecture. # =20 -as-option =3D $(shell if $(CC) $(CFLAGS) $(1) -Wa,-Z -c -o /dev/null \ - -xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; \ - else echo "$(2)"; fi ;) - cflags-y :=3D =20 # --U+BazGySraz5kW0T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFCBk3z1K+teJFxZ9wRAkIJAJ9CNK4b7WJlVk+xsbDN7uFBLFLzSwCYxpe2 a8kGpN6ulVxJby38Xbvlqw== =REKX -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- From ralf@linux-mips.org Sun Feb 6 18:09:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 06 Feb 2005 18:09:32 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:63429 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 6 Feb 2005 18:08: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 j16I4A9t006955 for ; Sun, 6 Feb 2005 18:04:10 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j16I49Me006954 for linux-mips@linux-mips.org; Sun, 6 Feb 2005 18:04:09 GMT Resent-Message-Id: <200502061804.j16I49Me006954@dea.linux-mips.net> Date: Sun, 6 Feb 2005 18:03:08 +0000 From: Ralf Baechle To: Paul Mundt , Sam Ravnborg , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Add as-option to top-level Makefile Message-ID: <20050206180308.GA21172@linux-mips.org> References: <20050206170347.GB27853@linux-sh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206170347.GB27853@linux-sh.org> User-Agent: Mutt/1.4.1i Resent-From: ralf@linux-mips.org Resent-Date: Sun, 6 Feb 2005 18:04:09 +0000 Resent-To: 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: 7173 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: 1010 Lines: 24 On Sun, Feb 06, 2005 at 07:03:47PM +0200, Paul Mundt wrote: > cc-option can presently not be used for checking as flags. It seems like > MIPS ran into this already and added their own as-option (which at this > point seems to be completely unused on MIPS, so perhaps it's worth > removing entirely from there). > > This patch moves the definition to the top-level Makefile so that others > can make use of it (sh wants this with newer binutils that allow for ISA > tuning, for instance). > > Additionally, it may make more sense to move the -Wa$(comma) stuff into > as-option directly so it doesn't get repeated all over the place (though > it seems unlikely that there will be enough users that actually care > about this). For MIPS as-option became unused when old binutils versions finally had to be retired. Patch looks good to me but since it's sort of a no-op patch I won't merge it into linux-mips.org but if accepted rather wait until it comes to me vi Linus's patches, as usual. Thanks, Ralf From ibrahim@schenk.isar.de Mon Feb 7 07:44:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 07:44:41 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:35099 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 07:44:26 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j177hjH24018; Mon, 7 Feb 2005 08:43:45 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j177hbc04309; Mon, 7 Feb 2005 08:43:44 +0100 Message-ID: <42071C29.3030507@schenk.isar.de> Date: Mon, 07 Feb 2005 08:43:37 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Lachwani CC: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: Titan ethernet and little endian References: <42023C54.7060801@schenk.isar.de> <420269C1.6050701@mvista.com> In-Reply-To: <420269C1.6050701@mvista.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7174 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 466 Lines: 23 Manish Lachwani wrote: > Hi ! > > So, have you got the titan to work in the LE mode? Are you using the > Yosemite board? Does this patch break BE? > > Please do let us know. > > Thanks > Manish Lachwani > > Hi! Yes I have got the titan work in LE mode. And yes I am using the Yosemite board. And no this patch does not break BE. I haven't actually tested that but all the changes I made are between #ifdef LITTLE_ENDIAN and #endif. Thanks Rojhalat Ibrahim From ibrahim@schenk.isar.de Mon Feb 7 08:10:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 08:10:30 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:39195 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 08:10:14 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j178ADH24156; Mon, 7 Feb 2005 09:10:13 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j178ADc04488; Mon, 7 Feb 2005 09:10:13 +0100 Message-ID: <42072264.6000001@schenk.isar.de> Date: Mon, 07 Feb 2005 09:10:12 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> In-Reply-To: <20050204004028.GC22311@linux-mips.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7175 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 2000 Lines: 63 Ralf Baechle wrote: > On Tue, Jan 18, 2005 at 03:44:51PM +0100, Rojhalat Ibrahim wrote: > > >>is there anything special I have to do >>when I want to use more than 512MB of memory? >>My Yosemite board works fine with 512MB >>but when I try 1GB it crashes in 32bit mode >>with highmem and also in 64bit mode. >>The boot monitor (PMON) maps the 1024MB >>to physical addresses 0x0000.0000 - 0x4000.0000. > > > Can you try below patch? > > Ralf > > --- linux/arch/mips/mm/c-r4k.c 2004-12-07 02:30:50.000000000 +0000 > +++ linux/arch/mips/mm/c-r4k.c 2005-02-04 00:31:34.623814760 +0000 > @@ -566,7 +566,10 @@ > > if (!cpu_has_ic_fills_f_dc) { > unsigned long addr = (unsigned long) page_address(page); > - r4k_blast_dcache_page(addr); > + if (addr) > + r4k_blast_dcache_page(addr); > + else > + r4k_blast_dcache(); > if (!cpu_icache_snoops_remote_store) > r4k_blast_scache_page(addr); > ClearPageDcacheDirty(page); > With a slightly extended patch it actually works. But afterwards I get a lot of Illegal instructions and Segmentation faults, where there shouldn't be any. Below is the patch I used. Thanks Rojhalat Ibrahim --- linux/arch/mips/mm/c-r4k.c 2005-01-03 10:23:27.000000000 +0100 +++ linux-2.6.10/arch/mips/mm/c-r4k.c 2005-02-07 09:04:27.000000000 +0100 @@ -566,9 +566,17 @@ if (!cpu_has_ic_fills_f_dc) { unsigned long addr = (unsigned long) page_address(page); - r4k_blast_dcache_page(addr); + if (addr) + r4k_blast_dcache_page(addr); + else + r4k_blast_dcache(); if (!cpu_icache_snoops_remote_store) - r4k_blast_scache_page(addr); + { + if (addr) + r4k_blast_scache_page(addr); + else + r4k_blast_scache(); + } ClearPageDcacheDirty(page); } From anemo@mba.ocn.ne.jp Mon Feb 7 10:24:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 10:25:13 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:60184 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Mon, 7 Feb 2005 10:24:57 +0000 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 7 Feb 2005 10:24:55 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 611F9239E39; Mon, 7 Feb 2005 19:24:51 +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 j17AOoRm047578; Mon, 7 Feb 2005 19:24:51 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 07 Feb 2005 19:24:50 +0900 (JST) Message-Id: <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup From: Atsushi Nemoto In-Reply-To: <20050204145803.GA5618@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> 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: 7176 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: 787 Lines: 23 >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle said: ralf> That's not a new feature in the MIPS world; the R10000 family ralf> introduced that first and Linux knows how to make use of it. So ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K. 20KC Users Manual says it has physically indexed data cache. --- linux-mips.org/arch/mips/mm/c-r4k.c 2005-02-07 19:06:54.598390493 +0900 +++ linux-mips/arch/mips/mm/c-r4k.c 2005-02-07 19:10:38.779771207 +0900 @@ -1016,6 +1016,8 @@ case CPU_R10000: case CPU_R12000: break; + case CPU_20KC: /* physically indexed */ + break; case CPU_24K: if (!(read_c0_config7() & (1 << 16))) default: For other MIPS64 core, 5Kc has virtually indexed cache. How about 25KF? --- Atsushi Nemoto From yuasa@hh.iij4u.or.jp Mon Feb 7 12:32:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 12:32:51 +0000 (GMT) Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:2762 "EHLO mo01.iij4u.or.jp") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 12:32:34 +0000 Received: MO(mo01)id j17CWUPI019467; Mon, 7 Feb 2005 21:32:30 +0900 (JST) Received: MDO(mdo01) id j17CWTsU011632; Mon, 7 Feb 2005 21:32:30 +0900 (JST) Received: 4UMRO01 id j17CWSQS010822; Mon, 7 Feb 2005 21:32:28 +0900 (JST) from stratos (localhost [127.0.0.1]) (authenticated) Date: Mon, 7 Feb 2005 21:32:27 +0900 From: Yoichi Yuasa To: Atsushi Nemoto Cc: yuasa@hh.iij4u.or.jp, ralf@linux-mips.org, nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-Id: <20050207213227.29f2d89b.yuasa@hh.iij4u.or.jp> In-Reply-To: <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> X-Mailer: Sylpheed version 1.0.0 (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: 7177 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: 941 Lines: 27 On Mon, 07 Feb 2005 19:24:50 +0900 (JST) Atsushi Nemoto wrote: > >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle said: > ralf> That's not a new feature in the MIPS world; the R10000 family > ralf> introduced that first and Linux knows how to make use of it. So > ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K. > > 20KC Users Manual says it has physically indexed data cache. > > --- linux-mips.org/arch/mips/mm/c-r4k.c 2005-02-07 19:06:54.598390493 +0900 > +++ linux-mips/arch/mips/mm/c-r4k.c 2005-02-07 19:10:38.779771207 +0900 > @@ -1016,6 +1016,8 @@ > case CPU_R10000: > case CPU_R12000: > break; > + case CPU_20KC: /* physically indexed */ > + break; > case CPU_24K: > if (!(read_c0_config7() & (1 << 16))) > default: > > For other MIPS64 core, 5Kc has virtually indexed cache. How about 25KF? 25Kf also has virtually indexed cache. Yoichi From dom@mips.com Mon Feb 7 12:37:07 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 12:37:22 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:32529 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 12:37:07 +0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1Cy8Db-0005DU-00; Mon, 07 Feb 2005 12:42:19 +0000 Received: from arsenal.mips.com ([192.168.192.197]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Cy88J-0005Fs-00; Mon, 07 Feb 2005 12:36:51 +0000 Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian)) id 1Cy88I-0008AS-00; Mon, 07 Feb 2005 12:36:50 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16903.24802.504192.330272@arsenal.mips.com> Date: Mon, 7 Feb 2005 12:36:50 +0000 To: Atsushi Nemoto Cc: ralf@linux-mips.org, nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup In-Reply-To: <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.897, required 4, AWL, BAYES_00) 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: 7178 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: dom@mips.com Precedence: bulk X-list: linux-mips Content-Length: 281 Lines: 18 Atsushi Nemoto (anemo@mba.ocn.ne.jp) writes: > 20KC Users Manual says it has physically indexed data cache. That's correct. > For other MIPS64 core, 5Kc has virtually indexed cache. Yes. > How about 25KF? Physically indexed, it's a descendent of the 20Kc core. -- Dominic From dom@mips.com Mon Feb 7 13:53:15 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 13:53:31 +0000 (GMT) Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:37639 "EHLO dmz.algor.co.uk") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 13:53:15 +0000 Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com) by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1Cy9PI-0006bH-00; Mon, 07 Feb 2005 13:58:28 +0000 Received: from arsenal.mips.com ([192.168.192.197]) by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Cy9Jy-0006FY-00; Mon, 07 Feb 2005 13:52:58 +0000 Received: from dom by arsenal.mips.com with local (Exim 3.35 #1 (Debian)) id 1Cy9Jy-0008Fl-00; Mon, 07 Feb 2005 13:52:58 +0000 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16903.29369.622451.447313@arsenal.mips.com> Date: Mon, 7 Feb 2005 13:52:57 +0000 To: Dominic Sweetman Cc: Atsushi Nemoto , ralf@linux-mips.org, nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup In-Reply-To: <16903.24802.504192.330272@arsenal.mips.com> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> <16903.24802.504192.330272@arsenal.mips.com> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-MTUK-Scanner: Found to be clean X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.897, required 4, AWL, BAYES_00) 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: 7179 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: dom@mips.com Precedence: bulk X-list: linux-mips Content-Length: 1037 Lines: 42 Interesting, > Atsushi Nemoto (anemo@mba.ocn.ne.jp) writes: > > > 20KC Users Manual says it has physically indexed data cache. > > That's correct. > > > For other MIPS64 core, 5Kc has virtually indexed cache. > > Yes. > > > How about 25KF? > > Physically indexed, it's a descendent of the 20Kc core. When Yoichi said > 25Kf also has virtually indexed cache I assume s/he meant the I-cache. Here is the official MIPS Technologies line (and we kind of ought to know): o The 25KF D-cache is physically indexed (and of course physically tagged). o The 25KF I-cache is virtually indexed and virtually tagged - the tag includes the ASID to reduce the number of occasions on which you have to invalidate all the lines from a particular process. o A 25KF secondary cache, if provided, is physically indexed and tagged. -- Dominic Sweetman, MIPS Technologies (UK) The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200 http://www.mips.com From yuasa@hh.iij4u.or.jp Mon Feb 7 14:04:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 14:04:32 +0000 (GMT) Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:13272 "EHLO mo00.iij4u.or.jp") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 14:04:17 +0000 Received: MO(mo00) for id j17E4E48010754; Mon, 7 Feb 2005 23:04:14 +0900 (JST) Received: MDO(mdo00) id j17E4DPR013430; Mon, 7 Feb 2005 23:04:13 +0900 (JST) Received: 4UMRO01 id j17E4C4R024464; Mon, 7 Feb 2005 23:04:13 +0900 (JST) from stratos (localhost [127.0.0.1]) for ; (authenticated) Date: Mon, 7 Feb 2005 23:04:11 +0900 From: Yoichi Yuasa To: linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-Id: <20050207230411.4a928d35.yuasa@hh.iij4u.or.jp> In-Reply-To: <20050207213227.29f2d89b.yuasa@hh.iij4u.or.jp> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> <20050207213227.29f2d89b.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 1.0.0 (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: 7180 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: 1114 Lines: 32 On Mon, 7 Feb 2005 21:32:27 +0900 Yoichi Yuasa wrote: > On Mon, 07 Feb 2005 19:24:50 +0900 (JST) > Atsushi Nemoto wrote: > > > >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle said: > > ralf> That's not a new feature in the MIPS world; the R10000 family > > ralf> introduced that first and Linux knows how to make use of it. So > > ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K. > > > > 20KC Users Manual says it has physically indexed data cache. > > > > --- linux-mips.org/arch/mips/mm/c-r4k.c 2005-02-07 19:06:54.598390493 +0900 > > +++ linux-mips/arch/mips/mm/c-r4k.c 2005-02-07 19:10:38.779771207 +0900 > > @@ -1016,6 +1016,8 @@ > > case CPU_R10000: > > case CPU_R12000: > > break; > > + case CPU_20KC: /* physically indexed */ > > + break; > > case CPU_24K: > > if (!(read_c0_config7() & (1 << 16))) > > default: > > > > For other MIPS64 core, 5Kc has virtually indexed cache. How about 25KF? > > 25Kf also has virtually indexed cache. Sorry, D-cahce is physically indexed cache. Yoichi From news@robertmichel.de Mon Feb 7 16:37:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 16:38:19 +0000 (GMT) Received: from ms-1.rz.RWTH-Aachen.DE ([IPv6:::ffff:134.130.3.130]:47293 "EHLO ms-dienst.rz.rwth-aachen.de") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 16:37:59 +0000 Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IBJ00J8HVJAHO@ms-dienst.rz.rwth-aachen.de> for linux-mips@linux-mips.org; Mon, 07 Feb 2005 17:37:58 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 07 Feb 2005 17:37:58 +0100 (MET) Received: from robins (robins.karman5.RWTH-Aachen.DE [134.130.104.75]) by relay.rwth-aachen.de (8.13.0/8.13.0/1) with ESMTP id j17GbvmT028394; Mon, 07 Feb 2005 17:37:57 +0100 (MET) Received: from rob by robins with local (Exim 3.36 #1 (Debian)) id 1CyBtd-00032O-00; Mon, 07 Feb 2005 17:37:57 +0100 Date: Mon, 07 Feb 2005 17:37:57 +0100 From: Robert Michel Subject: Re: patch like kexec for MIPS possible? In-reply-to: <20050206002809.GV28252@rembrandt.csv.ica.uni-stuttgart.de> To: Thiemo Seufer Cc: linux-mips Message-id: <20050207163757.GA1741@mail.robertmichel.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20050205165019.GC3071@mail.robertmichel.de> <20050205174150.GU28252@rembrandt.csv.ica.uni-stuttgart.de> <20050205191110.GD3071@mail.robertmichel.de> <20050206002809.GV28252@rembrandt.csv.ica.uni-stuttgart.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: 7181 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: news@robertmichel.de Precedence: bulk X-list: linux-mips Content-Length: 3619 Lines: 97 Salve all & Thiemo! First thank you all for your answers, as I understud you right, is there no restriction by the MIPS CPU/Memory architecture that makes a patch for starting another kernel unpossible. This was the focus of my question - not the use of this. ;) Thiemo Seufer schrieb am Sonntag, den 06. Februar 2005 um 01:28h: > 30 seconds for the tftp, and you have to hope the previous > kernel left everything in a sane state. I know now (due your answers) u-boot which supports tftp like grub. But both lake SSH2 to access and control the bootloader during boot time. > > - perversive computing, the box could be on a place without > > physicaly access > > You don't want to do that without a safe fallback (aka serial console). I _will_ be able to to this - not because I need it today - I'm just shure that it will be a handy feature. You are right, it's usefull to have a safe fallback, but on many embedded systems you need a screw driver, maby soldering iron and a RS232 port for "debricking a box". Beside of a hardware-hangup a box could have a hangup because of a user software error, kernel error or a black hat attack. Kernel do have security updates - so if your box does have any kind of interface/network it will need kernelupgrades and it exist the danger, that someone attack and "ownz" this box. When you have a watchdog or just a timer to reboot the box the primary kernel form a secure, read-only medium (CD-Rom, Floppy, E-Prom...). After booting a clean system, this box could ask a server via a secure Network what it should do: - booting the lokal system - overwrite the lokal system with a clean/newer system. Now the question, should the bootloader runs SSH2 or would it better to have an old, sercure, rudimental kernel to do this. (Hardcore paranoiacs would use multiple tricks to make the box secure) IMHO is it not only more easy to use a kernel instead of forking a bootloader - also in case of unsecure code, it is more easier to use a normal kernel/dep patch, than write this myself for my personal bootloader-fork. Today you could realise this with RS232 and a second box, second IP..... this would make the systems more expensive, bigger, create a higher power consumption - so somethink that nobody likes for perversive computing. Probably the link to the IBM article without expaining my idea was not so good, that article is IMHO concentrating to much on the speed of reboot. My point is that such a feature could have a use for different cases (even more that I can imagine). I just see that it would be nice to have this feature also on non x86 platforms - so this is why I ask you if it would be principle possible to run it on the MIPS platform. > > So my point is not to boot a machine continuously, > > but to expand the bootchain: > > > > IMHO would be the most powerfull and flexible way > > to boot a linux kernel, > > to boot it just from an other linux kernel. > > ;) > > What if any of both is buggy? Either you have a working fallback, > or you'll be screwed sooner or later. No question, sooner or later will fail every system, but the question is to make the probability as low as possible. Greetings, rob PS: The radio for the Huygens to Cassini communications had a small bandwidth and the frequencies was written in ROM (to minimice the power consumption). But the enginneers forgot to calculate the doppler effect - so on the first look it seems that no data receiving on Cassini would be possible. The workaround was a changed flight path of Cassini to change the doppler effect. http://www.thespacereview.com/article/306/1 From mlachwani@mvista.com Mon Feb 7 17:30:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 17:30:39 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:42741 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 17:30:24 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id B1DEA187F9; Mon, 7 Feb 2005 09:30:21 -0800 (PST) Message-ID: <4207A5AD.6090806@mvista.com> Date: Mon, 07 Feb 2005 09:30:21 -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: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: Titan ethernet and little endian References: <42023C54.7060801@schenk.isar.de> <420269C1.6050701@mvista.com> <42071C29.3030507@schenk.isar.de> In-Reply-To: <42071C29.3030507@schenk.isar.de> 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: 7182 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: 655 Lines: 34 Rojhalat Ibrahim wrote: > Manish Lachwani wrote: > >> Hi ! >> >> So, have you got the titan to work in the LE mode? Are you using the >> Yosemite board? Does this patch break BE? >> >> Please do let us know. >> >> Thanks >> Manish Lachwani >> >> > > Hi! > > Yes I have got the titan work in LE mode. And yes I am using the > Yosemite board. And no this patch does not break BE. I haven't > actually tested that but all the changes I made are between > #ifdef LITTLE_ENDIAN and #endif. > > Thanks > Rojhalat Ibrahim > > Ok, as long as the changes are in #ifdef. Although, your patch did not indicate the "#ifdef LITTLE_ENDIAN" Thanks Manish Lachwani From ddaney@avtrex.com Mon Feb 7 19:28:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 19:28:24 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:21883 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 19:28:08 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 11:28:04 -0800 Message-ID: <4207C142.6070804@avtrex.com> Date: Mon, 07 Feb 2005 11:28:02 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: andreev , Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: Strace doesn't work on linux-2.4.28 and later References: <41FF876B.3070407@niisi.msk.ru> In-Reply-To: <41FF876B.3070407@niisi.msk.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 19:28:04.0966 (UTC) FILETIME=[25506060:01C50D4B] 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: 7183 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: 1621 Lines: 52 andreev wrote: > Hi, list. > > We are using the latest kernel from mips-linux CVS and there is a > problem with ptrace. > > When syscall with 5 or more arguments are traced, the fifth argument of > the syscall is overwritten > by tracing code. This error causes problems with strace. For example, > you can't trace dynamically linked > applications, because ld.so calls mmap which has 6 arguments. > This patch broke it: http://www.linux-mips.org/archives/linux-cvs/2004-11/msg00116.html RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v retrieving revision 1.18.2.13 retrieving revision 1.18.2.14 diff -u -p -r1.18.2.13 -r1.18.2.14 --- linux/arch/mips/kernel/Attic/scall_o32.S 2004/04/26 15:06:02 1.18.2.13 +++ linux/arch/mips/kernel/Attic/scall_o32.S 2004/11/25 09:43:59 1.18.2.14 @@ -121,9 +121,9 @@ reschedule: trace_a_syscall: SAVE_STATIC - sw t2, PT_R1(sp) + sw t2, PT_SCRATCH0(sp) jal syscall_trace - lw t2, PT_R1(sp) + lw t2, PT_SCRATCH0(sp) lw a0, PT_R4(sp) # Restore argument registers lw a1, PT_R5(sp) PT_SCRATCH0(sp) = 16(sp) which is where arg5 is stored. This overwrites it. In arch/mips/tools/offset.c we have: offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[4]); offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[5]); I am thinking of testing a patch where I change them to: offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[0]); offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[1]); Any needed argument registers are already saved in and restored from the regs array so overwriting the stack area reserved for them should be OK. David Daney From ddaney@avtrex.com Mon Feb 7 19:39:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 19:39:33 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:56443 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 19:39:16 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 11:39:14 -0800 Message-ID: <4207C3E0.7070405@avtrex.com> Date: Mon, 07 Feb 2005 11:39:12 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Daney CC: andreev , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Strace doesn't work on linux-2.4.28 and later References: <41FF876B.3070407@niisi.msk.ru> <4207C142.6070804@avtrex.com> In-Reply-To: <4207C142.6070804@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 19:39:14.0679 (UTC) FILETIME=[B47E7870:01C50D4C] 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: 7184 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: 2172 Lines: 65 David Daney wrote: > andreev wrote: > >> Hi, list. >> >> We are using the latest kernel from mips-linux CVS and there is a >> problem with ptrace. >> >> When syscall with 5 or more arguments are traced, the fifth argument >> of the syscall is overwritten >> by tracing code. This error causes problems with strace. For example, >> you can't trace dynamically linked >> applications, because ld.so calls mmap which has 6 arguments. >> > > This patch broke it: > > http://www.linux-mips.org/archives/linux-cvs/2004-11/msg00116.html > > RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v > retrieving revision 1.18.2.13 > retrieving revision 1.18.2.14 > diff -u -p -r1.18.2.13 -r1.18.2.14 > --- linux/arch/mips/kernel/Attic/scall_o32.S 2004/04/26 15:06:02 > 1.18.2.13 > +++ linux/arch/mips/kernel/Attic/scall_o32.S 2004/11/25 09:43:59 > 1.18.2.14 > @@ -121,9 +121,9 @@ reschedule: > > trace_a_syscall: > SAVE_STATIC > - sw t2, PT_R1(sp) > + sw t2, PT_SCRATCH0(sp) > jal syscall_trace > - lw t2, PT_R1(sp) > + lw t2, PT_SCRATCH0(sp) > > lw a0, PT_R4(sp) # Restore argument registers > lw a1, PT_R5(sp) > > PT_SCRATCH0(sp) = 16(sp) which is where arg5 is stored. This overwrites > it. > > In arch/mips/tools/offset.c we have: > > offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[4]); > offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[5]); > > I am thinking of testing a patch where I change them to: > > offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[0]); > offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[1]); > > Any needed argument registers are already saved in and restored from the > regs array so overwriting the stack area reserved for them should be OK. > I now think that is bogus reasoning as the first four slots can be clobbered by the compiler. It seems that t2 must be saved somewhere in the regs list. I am not sure what the problem with PT_R1(sp) was, but it seems like a good candidate. Perhaps PT_R26 or PT_R27 (k0, k1) would be a better place to store t2 as I don't think k0 or k1 are ever stored. David Daney. From tom@voda.cz Mon Feb 7 19:53:13 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 19:53:32 +0000 (GMT) Received: from gw.voda.cz ([IPv6:::ffff:212.24.154.90]:6584 "EHLO smtp.voda.cz") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 19:53:13 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.voda.cz (Postfix) with ESMTP id 83C0C10F02 for ; Mon, 7 Feb 2005 20:53:07 +0100 (CET) Received: from smtp.voda.cz ([127.0.0.1]) by localhost (gw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09153-04 for ; Mon, 7 Feb 2005 20:53:04 +0100 (CET) Received: from [10.1.1.77] (unknown [213.151.77.162]) by smtp.voda.cz (Postfix) with ESMTP id B31B910EFA for ; Mon, 7 Feb 2005 20:53:03 +0100 (CET) Message-ID: <4207C71F.7050204@voda.cz> Date: Mon, 07 Feb 2005 20:53:03 +0100 From: =?ISO-8859-2?Q?Tom_Vr=E1na?= Organization: VODA IT consulting User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: ADM5120: time.c issues ? Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at voda.cz 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: 7185 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: tom@voda.cz Precedence: bulk X-list: linux-mips Content-Length: 3613 Lines: 102 Hi, I made my attempt to port ADM5120 stuff from the prehistoric 2.4.18 kernel to recent 2.4.27-mipscvs. I get to boot, but: time.c originally uses: extern unsigned int mips_counter_frequency; from timex.h but in 2.4.27 the timex.h changed to: extern unsigned int mips_hpt_frequency; Jeroen uses just a localy defined mips_counter_frequency in his 2.6.x port. Using jeroens time.c the system boots painfully slow, sort of loops int the beginning and the finally freezes on the FPU emulator... any suggestions ? Thanks Tom LINUX/5120 started... CPU revision is: 0001800b Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes. Primary data cache 8kB, 2-way, linesize 16 bytes. Linux version 2.4.27-mipscvs-20050128 (tom@jackal) (gcc version 3.2) #11 Po .ono 7 19:12:23 CET 2005 am5120_setup() starts. System has PCI BIOS Determined physical RAM map: memory: 00d2a000 @ 002d6000 (usable) Initial ramdisk at: 0x80157000 (1404928 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram0 console=ttyS0 CPU clock: 175MHz CPU revision is: 0001800b Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes. Primary data cache 8kB, 2-way, linesize 16 bytes. Linux version 2.4.27-mipscvs-20050128 (tom@jackal) (gcc version 3.2) #11 Po .ono 7 19:12:23 CET 2005 am5120_setup() starts. System has PCI BIOS Determined physical RAM map: memory: 00d2a000 @ 002d6000 (usable) Initial ramdisk at: 0x80157000 (1404928 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram0 console=ttyS0 CPU clock: 175MHz Calibrating delay loop... 174.48 BogoMIPS Memory: 13292k/13480k available (1160k kernel code, 188k reserved, 1464k data, 88k init, 0k highmem) Dentry cache hash table entries: 2048 (order: 2, 16384 bytes) Inode cache hash table entries: 1024 (order: 1, 8192 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Autoconfig PCI channel 0x801568c8 Scanning bus 00, I/O 0x11500000:0x115ffff0, Mem 0x11400000:0x11500000 00:00.0 Class 0600: 1317:5120 Mem unavailable -- skipping I/O unavailable -- skipping 00:02.0 Class 0200: 168c:0013 (rev 01) Mem at 0x11400000 [size=0x10000] Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS28 at 0x03f8 (irq = 4) is a 16450 ttyS29 at 0x02f8 (irq = 3) is a 16450 ttyS30 at 0x03e8 (irq = 4) is a 16450 RAMDISK driver initialized: 16 RAM disks of 5120K size 1024 blocksize Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 2048) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1372k freed VFS: Mounted root (ext2 filesystem) readonly. Freeing prom memory: 0kb freed Freeing unused kernel memory: 88k freed Algorithmics/MIPS FPU Emulator v1.5 -- Tomas Vrana -------------------------- VODA IT consulting, Borkovany 48, 691 75 http://www.voda.cz/ phone: +420 519 419 416 mobile: +420 603 469 305 UIN: 105142752 From flo@rfc822.org Mon Feb 7 20:49:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 20:49:17 +0000 (GMT) Received: from hydra.gt.owl.de ([IPv6:::ffff:195.71.99.218]:54442 "EHLO hydra.gt.owl.de") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 20:49:01 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 104) id 01DA9198E2B; Mon, 7 Feb 2005 21:48:59 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 7D9F5138002; Mon, 7 Feb 2005 21:48:51 +0100 (CET) Date: Mon, 7 Feb 2005 21:48:51 +0100 From: Florian Lohoff To: Tom =?iso-8859-1?Q?Vr=E1na?= Cc: linux-mips@linux-mips.org Subject: Re: ADM5120: time.c issues ? Message-ID: <20050207204851.GD17199@paradigm.rfc822.org> References: <4207C71F.7050204@voda.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zaRBsRFn0XYhEU69" Content-Disposition: inline In-Reply-To: <4207C71F.7050204@voda.cz> Organization: rfc822 - pure communication User-Agent: Mutt/1.5.4i 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: 7186 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: flo@rfc822.org Precedence: bulk X-list: linux-mips Content-Length: 758 Lines: 31 --zaRBsRFn0XYhEU69 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 07, 2005 at 08:53:03PM +0100, Tom Vr=E1na wrote: > LINUX/5120 started... Cool - Linux on 64K 8085 Machine :) http://www-03.ibm.com/ibm/history/exhibits/pc/pc_6.html Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. --zaRBsRFn0XYhEU69 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCB9QzUaz2rXW+gJcRAvIWAKCXjobClY0QM/H7Ak4HsghYjwXyugCfU0+M 5g8ZL3UTFS6G/ZX9RwcGjrA= =jKMH -----END PGP SIGNATURE----- --zaRBsRFn0XYhEU69-- From ralf@linux-mips.org Mon Feb 7 21:13:30 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 21:13:53 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:41176 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 21:13: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 j17L8TEC013864; Mon, 7 Feb 2005 21:08:29 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j17L8QmP013850; Mon, 7 Feb 2005 21:08:26 GMT Date: Mon, 7 Feb 2005 21:08:25 +0000 From: Ralf Baechle To: David Daney Cc: andreev , linux-mips@linux-mips.org Subject: Re: Strace doesn't work on linux-2.4.28 and later Message-ID: <20050207210825.GA6703@linux-mips.org> References: <41FF876B.3070407@niisi.msk.ru> <4207C142.6070804@avtrex.com> <4207C3E0.7070405@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4207C3E0.7070405@avtrex.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: 7187 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: 4764 Lines: 156 On Mon, Feb 07, 2005 at 11:39:12AM -0800, David Daney wrote: > > offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[4]); > > offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[5]); > > > >I am thinking of testing a patch where I change them to: > > > > offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[0]); > > offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[1]); > > > >Any needed argument registers are already saved in and restored from the > >regs array so overwriting the stack area reserved for them should be OK. > > > I now think that is bogus reasoning as the first four slots can be > clobbered by the compiler. > > It seems that t2 must be saved somewhere in the regs list. I am not > sure what the problem with PT_R1(sp) was, but it seems like a good > candidate. Perhaps PT_R26 or PT_R27 (k0, k1) would be a better place to > store t2 as I don't think k0 or k1 are ever stored. I was always planning to backport the newer fix from 2.6 which is simply storing the value in a caller saved register. You now reminded me of that omission ;-) Patch below, Ralf Index: arch/mips/kernel/scall_o32.S =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v retrieving revision 1.18.2.14 diff -u -r1.18.2.14 scall_o32.S --- arch/mips/kernel/scall_o32.S 25 Nov 2004 09:43:59 -0000 1.18.2.14 +++ arch/mips/kernel/scall_o32.S 7 Feb 2005 21:12:53 -0000 @@ -121,15 +121,14 @@ trace_a_syscall: SAVE_STATIC - sw t2, PT_SCRATCH0(sp) + move s0, sp jal syscall_trace - lw t2, PT_SCRATCH0(sp) lw a0, PT_R4(sp) # Restore argument registers lw a1, PT_R5(sp) lw a2, PT_R6(sp) lw a3, PT_R7(sp) - jalr t2 + jalr s0 li t0, -EMAXERRNO - 1 # error? sltu t0, t0, v0 Index: arch/mips/tools/offset.c =================================================================== RCS file: /home/cvs/linux/arch/mips/tools/Attic/offset.c,v retrieving revision 1.16.4.12 diff -u -r1.16.4.12 offset.c --- arch/mips/tools/offset.c 25 Nov 2004 09:43:59 -0000 1.16.4.12 +++ arch/mips/tools/offset.c 7 Feb 2005 21:12:53 -0000 @@ -12,7 +12,6 @@ #include #include #include -#include #include #include @@ -37,9 +36,6 @@ void output_ptreg_defines(void) { text("/* MIPS pt_regs offsets. */"); - offset("#define PT_SCRATCH0 ", struct pt_regs, pad0[4]); - offset("#define PT_SCRATCH1 ", struct pt_regs, pad0[5]); - offset("#define PT_R0 ", struct pt_regs, regs[0]); offset("#define PT_R1 ", struct pt_regs, regs[1]); offset("#define PT_R2 ", struct pt_regs, regs[2]); Index: arch/mips64/kernel/scall_64.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/Attic/scall_64.S,v retrieving revision 1.20.2.20 diff -u -r1.20.2.20 scall_64.S --- arch/mips64/kernel/scall_64.S 25 Nov 2004 09:43:59 -0000 1.20.2.20 +++ arch/mips64/kernel/scall_64.S 7 Feb 2005 21:12:53 -0000 @@ -102,15 +102,14 @@ trace_a_syscall: SAVE_STATIC - sd t2, PT_SCRATCH0(sp) + move s0, t2 jal syscall_trace - ld t2, PT_SCRATCH0(sp) ld a0, PT_R4(sp) # Restore argument registers ld a1, PT_R5(sp) ld a2, PT_R6(sp) ld a3, PT_R7(sp) - jalr t2 + jalr s0 li t0, -EMAXERRNO - 1 # error? sltu t0, t0, v0 Index: arch/mips64/kernel/scall_n32.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/Attic/scall_n32.S,v retrieving revision 1.2.2.17 diff -u -r1.2.2.17 scall_n32.S --- arch/mips64/kernel/scall_n32.S 25 Nov 2004 09:43:59 -0000 1.2.2.17 +++ arch/mips64/kernel/scall_n32.S 7 Feb 2005 21:12:53 -0000 @@ -106,15 +106,14 @@ trace_a_syscall: SAVE_STATIC - sd t2, PT_SCRATCH0(sp) + move s0, t2 jal syscall_trace - ld t2, PT_SCRATCH0(sp) ld a0, PT_R4(sp) # Restore argument registers ld a1, PT_R5(sp) ld a2, PT_R6(sp) ld a3, PT_R7(sp) - jalr t2 + jalr s0 li t0, -EMAXERRNO - 1 # error? sltu t0, t0, v0 Index: arch/mips64/kernel/scall_o32.S =================================================================== RCS file: /home/cvs/linux/arch/mips64/kernel/Attic/scall_o32.S,v retrieving revision 1.48.2.33 diff -u -r1.48.2.33 scall_o32.S --- arch/mips64/kernel/scall_o32.S 25 Nov 2004 09:43:59 -0000 1.48.2.33 +++ arch/mips64/kernel/scall_o32.S 7 Feb 2005 21:12:53 -0000 @@ -118,9 +118,8 @@ sd a6, PT_R10(sp) sd a7, PT_R11(sp) - sd t2, PT_SCRATCH0(sp) + move s0, t2 jal syscall_trace - ld t2, PT_SCRATCH0(sp) ld a0, PT_R4(sp) # Restore argument registers ld a1, PT_R5(sp) @@ -129,7 +128,7 @@ ld a4, PT_R8(sp) ld a5, PT_R9(sp) - jalr t2 + jalr s0 li t0, -EMAXERRNO - 1 # error? sltu t0, t0, v0 From ddaney@avtrex.com Mon Feb 7 21:20:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 21:21:13 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:33157 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 21:20:56 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 13:20:52 -0800 Message-ID: <4207DBB1.9000506@avtrex.com> Date: Mon, 07 Feb 2005 13:20:49 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: andreev , linux-mips@linux-mips.org Subject: Re: Strace doesn't work on linux-2.4.28 and later References: <41FF876B.3070407@niisi.msk.ru> <4207C142.6070804@avtrex.com> <4207C3E0.7070405@avtrex.com> <20050207210825.GA6703@linux-mips.org> In-Reply-To: <20050207210825.GA6703@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 21:20:52.0562 (UTC) FILETIME=[E71D9320:01C50D5A] 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: 7188 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: 598 Lines: 18 Ralf Baechle wrote: > Index: arch/mips/kernel/scall_o32.S > =================================================================== > RCS file: /home/cvs/linux/arch/mips/kernel/Attic/scall_o32.S,v > retrieving revision 1.18.2.14 > diff -u -r1.18.2.14 scall_o32.S > --- arch/mips/kernel/scall_o32.S 25 Nov 2004 09:43:59 -0000 1.18.2.14 > +++ arch/mips/kernel/scall_o32.S 7 Feb 2005 21:12:53 -0000 > @@ -121,15 +121,14 @@ > > trace_a_syscall: > SAVE_STATIC > - sw t2, PT_SCRATCH0(sp) > + move s0, sp ^^^^^^^^^^^^^ I think this should be "move s0, t2" as in scall_64.S et al. David Daney. From ralf@linux-mips.org Mon Feb 7 21:22:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 21:22:56 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:50904 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 21:22:42 +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 j17LHgxD014157; Mon, 7 Feb 2005 21:17:42 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j17LHgGg014156; Mon, 7 Feb 2005 21:17:42 GMT Date: Mon, 7 Feb 2005 21:17:42 +0000 From: Ralf Baechle To: David Daney Cc: andreev , linux-mips@linux-mips.org Subject: Re: Strace doesn't work on linux-2.4.28 and later Message-ID: <20050207211742.GB6703@linux-mips.org> References: <41FF876B.3070407@niisi.msk.ru> <4207C142.6070804@avtrex.com> <4207C3E0.7070405@avtrex.com> <20050207210825.GA6703@linux-mips.org> <4207DBB1.9000506@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4207DBB1.9000506@avtrex.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: 7189 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: 344 Lines: 14 On Mon, Feb 07, 2005 at 01:20:49PM -0800, David Daney wrote: > >@@ -121,15 +121,14 @@ > > > > trace_a_syscall: > > SAVE_STATIC > >- sw t2, PT_SCRATCH0(sp) > >+ move s0, sp > ^^^^^^^^^^^^^ > I think this should be "move s0, t2" as in scall_64.S et al. It should and what I've actually commited in CVS doesn't have this bug. Ralf From ralf@linux-mips.org Mon Feb 7 21:41:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 21:42:03 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:5593 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 21:41:48 +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 j17LaoKd014756; Mon, 7 Feb 2005 21:36:50 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j17Lams4014755; Mon, 7 Feb 2005 21:36:48 GMT Date: Mon, 7 Feb 2005 21:36:48 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050207213648.GC6703@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050207.192450.55145246.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: 7190 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: 696 Lines: 15 On Mon, Feb 07, 2005 at 07:24:50PM +0900, Atsushi Nemoto wrote: > >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle said: > ralf> That's not a new feature in the MIPS world; the R10000 family > ralf> introduced that first and Linux knows how to make use of it. So > ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K. > > 20KC Users Manual says it has physically indexed data cache. Correct - and just to make this CPU one of a rare breed in the MIPS world it also has virtually indexed, virtually tagged caches, similar to the Sibyte SB1. Sibyte still uses it's own cache code but eventually that should go away, so I've listed it also. Ralf From ralf@linux-mips.org Mon Feb 7 21:54:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 21:55:03 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:16601 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 7 Feb 2005 21:54:47 +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 j17LnnxQ015143; Mon, 7 Feb 2005 21:49:49 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j17Lnn4p015142; Mon, 7 Feb 2005 21:49:49 GMT Date: Mon, 7 Feb 2005 21:49:49 +0000 From: Ralf Baechle To: Dominic Sweetman Cc: Atsushi Nemoto , nigel@mips.com, linux-mips@linux-mips.org Subject: Re: c-r4k.c cleanup Message-ID: <20050207214949.GD6703@linux-mips.org> References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org> <20050207.192450.55145246.nemoto@toshiba-tops.co.jp> <16903.24802.504192.330272@arsenal.mips.com> <16903.29369.622451.447313@arsenal.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16903.29369.622451.447313@arsenal.mips.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: 7191 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: 486 Lines: 15 On Mon, Feb 07, 2005 at 01:52:57PM +0000, Dominic Sweetman wrote: > o The 25KF D-cache is physically indexed (and of course > physically tagged). > > o The 25KF I-cache is virtually indexed and virtually tagged - the tag > includes the ASID to reduce the number of occasions on which you > have to invalidate all the lines from a particular process. > > o A 25KF secondary cache, if provided, is physically indexed and > tagged. Ok, so I've added it also, thanks. Ralf From TheNop@gmx.net Mon Feb 7 22:52:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Feb 2005 22:52:43 +0000 (GMT) Received: from imap.gmx.net ([IPv6:::ffff:213.165.64.20]:62183 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Mon, 7 Feb 2005 22:52:28 +0000 Received: (qmail invoked by alias); 07 Feb 2005 22:52:21 -0000 Received: from c162014.adsl.hansenet.de (EHLO [192.168.0.1]) (213.39.162.14) by mail.gmx.net (mp007) with SMTP; 07 Feb 2005 23:52:21 +0100 X-Authenticated: #947741 Message-ID: <4207F163.4010605@gmx.net> Date: Mon, 07 Feb 2005 23:53:23 +0100 From: TheNop User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Kernel crash on yosemite Content-Type: text/plain; charset=us-ascii; 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: 7192 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: TheNop@gmx.net Precedence: bulk X-list: linux-mips Content-Length: 366 Lines: 16 Hi , This is my configuration: ~ yosemite board with RM9000 chip revision 1.1 ~ BusyBox 1.0 ~ Kernel 2.6.8.1 When I try to copy a large file (~ 3,5 Mb) within the NFS file system the kernel crashs without any output on the console. It could be a problem with the titan_ge driver, but I have no idee how to solve the problem. What can I do? Best regards TheNop From ralf@linux-mips.org Tue Feb 8 00:22:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 00:23:00 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:59098 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 00:22:44 +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 j180HhQt025257; Tue, 8 Feb 2005 00:17:43 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j180Hgnt025256; Tue, 8 Feb 2005 00:17:42 GMT Date: Tue, 8 Feb 2005 00:17:42 +0000 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050208001742.GA15336@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42072264.6000001@schenk.isar.de> 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: 7193 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: 2505 Lines: 71 On Mon, Feb 07, 2005 at 09:10:12AM +0100, Rojhalat Ibrahim wrote: > With a slightly extended patch it actually works. But afterwards > I get a lot of Illegal instructions and Segmentation faults, where > there shouldn't be any. Below is the patch I used. > --- linux/arch/mips/mm/c-r4k.c 2005-01-03 10:23:27.000000000 +0100 > +++ linux-2.6.10/arch/mips/mm/c-r4k.c 2005-02-07 09:04:27.000000000 +0100 > @@ -566,9 +566,17 @@ > > if (!cpu_has_ic_fills_f_dc) { > unsigned long addr = (unsigned long) page_address(page); > - r4k_blast_dcache_page(addr); > + if (addr) > + r4k_blast_dcache_page(addr); > + else > + r4k_blast_dcache(); > if (!cpu_icache_snoops_remote_store) > - r4k_blast_scache_page(addr); > + { > + if (addr) > + r4k_blast_scache_page(addr); > + else > + r4k_blast_scache(); > + } > ClearPageDcacheDirty(page); > } Blowing away the entire S-cache is extreme overkill. We really want to avoid this if possible as it'll have serious performance impact. As for the RM9000 that means we have a struct page pointer, therefore we know the physical address of the page and can perform a selective flush on the second level cache. See below for a patch which tries that. Obviously this one only tries to optimize performance a bit further but doesn't really solve the remaining problem. Ralf Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.101 diff -u -r1.101 c-r4k.c --- arch/mips/mm/c-r4k.c 7 Feb 2005 21:53:39 -0000 1.101 +++ arch/mips/mm/c-r4k.c 8 Feb 2005 00:18:17 -0000 @@ -566,9 +566,21 @@ if (!cpu_has_ic_fills_f_dc) { unsigned long addr = (unsigned long) page_address(page); - r4k_blast_dcache_page(addr); - if (!cpu_icache_snoops_remote_store) - r4k_blast_scache_page(addr); + + if (addr) + r4k_blast_dcache_page(addr); + else + r4k_blast_dcache(); + + if (!cpu_icache_snoops_remote_store) { + if (addr) + r4k_blast_scache_page(addr); + else { + addr = page_to_pfn(page) << PAGE_SHIFT; + addr = CKSEG + (addr & ~((1UL << 24) - 1)); + r4k_blast_scache_page_indexed(addr); + } + } ClearPageDcacheDirty(page); } From ralf@linux-mips.org Tue Feb 8 01:35:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 01:35:15 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:62939 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 01:35:00 +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 j181U0mY027116; Tue, 8 Feb 2005 01:30:00 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j181U0hH027115; Tue, 8 Feb 2005 01:30:00 GMT Date: Tue, 8 Feb 2005 01:30:00 +0000 From: Ralf Baechle To: TheNop Cc: linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite Message-ID: <20050208013000.GA6131@linux-mips.org> References: <4207F163.4010605@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4207F163.4010605@gmx.net> 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: 7194 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: 683 Lines: 20 On Mon, Feb 07, 2005 at 11:53:23PM +0100, TheNop wrote: > This is my configuration: > ~ yosemite board with RM9000 chip revision 1.1 > ~ BusyBox 1.0 > ~ Kernel 2.6.8.1 > > When I try to copy a large file (~ 3,5 Mb) within the NFS file system > the kernel crashs without any output on the console. > It could be a problem with the titan_ge driver, but I have no idee how > to solve the problem. > > What can I do? There have been various fixes to the network driver since then so I recommend you upgrade your kernel. One problem you're going to encounter with recent kernels is that they only support the Titan 1.2 part which I think are the ones in volume production. Ralf From mlachwani@mvista.com Tue Feb 8 01:47:26 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 01:47:41 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23022 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 01:47:26 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id AB827189DA; Mon, 7 Feb 2005 17:47:24 -0800 (PST) Message-ID: <42081A2C.5060503@mvista.com> Date: Mon, 07 Feb 2005 17:47:24 -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: TheNop , linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> In-Reply-To: <20050208013000.GA6131@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: 7195 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: 862 Lines: 36 Ralf Baechle wrote: >On Mon, Feb 07, 2005 at 11:53:23PM +0100, TheNop wrote: > > > >>This is my configuration: >>~ yosemite board with RM9000 chip revision 1.1 >>~ BusyBox 1.0 >>~ Kernel 2.6.8.1 >> >>When I try to copy a large file (~ 3,5 Mb) within the NFS file system >>the kernel crashs without any output on the console. >>It could be a problem with the titan_ge driver, but I have no idee how >>to solve the problem. >> >>What can I do? >> >> > >There have been various fixes to the network driver since then so I >recommend you upgrade your kernel. One problem you're going to encounter >with recent kernels is that they only support the Titan 1.2 part which I >think are the ones in volume production. > > Ralf > > > However, adding support for Titan 1.0 and 1.1 in the GE driver should be fairly straight forward. Thanks Manish Lachwani From ralf@linux-mips.org Tue Feb 8 01:57:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 01:57:21 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:14044 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 01:57:06 +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 j181puf9027715; Tue, 8 Feb 2005 01:51:56 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j181ptZh027714; Tue, 8 Feb 2005 01:51:55 GMT Date: Tue, 8 Feb 2005 01:51:55 +0000 From: Ralf Baechle To: Manish Lachwani Cc: TheNop , linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite Message-ID: <20050208015155.GB15336@linux-mips.org> References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42081A2C.5060503@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: 7196 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: 497 Lines: 13 On Mon, Feb 07, 2005 at 05:47:24PM -0800, Manish Lachwani wrote: > >recommend you upgrade your kernel. One problem you're going to encounter > >with recent kernels is that they only support the Titan 1.2 part which I > >think are the ones in volume production. > > However, adding support for Titan 1.0 and 1.1 in the GE driver should be > fairly straight forward. True, the CVS log should provide reasonable information about that. What can't be sanely retrofitted is SMP for < 1.2. Ralf From mlachwani@mvista.com Tue Feb 8 02:02:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 02:02:26 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:29678 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 02:02:11 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id 35B9E189DA; Mon, 7 Feb 2005 18:02:09 -0800 (PST) Message-ID: <42081DA0.6070301@mvista.com> Date: Mon, 07 Feb 2005 18:02:08 -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: TheNop , linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> <20050208015155.GB15336@linux-mips.org> In-Reply-To: <20050208015155.GB15336@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: 7197 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: 692 Lines: 28 Ralf Baechle wrote: >On Mon, Feb 07, 2005 at 05:47:24PM -0800, Manish Lachwani wrote: > > > >>>recommend you upgrade your kernel. One problem you're going to encounter >>>with recent kernels is that they only support the Titan 1.2 part which I >>>think are the ones in volume production. >>> >>> >>However, adding support for Titan 1.0 and 1.1 in the GE driver should be >>fairly straight forward. >> >> > >True, the CVS log should provide reasonable information about that. What >can't be sanely retrofitted is SMP for < 1.2. > > Ralf > > I completely agree. In any case, I dont think the CVS sources ever supported SMP for Titan < 1.2, correct? Thanks Manish Lachwani From ralf@linux-mips.org Tue Feb 8 02:38:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 02:39:04 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:41948 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 02:38: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 j182XnOi028647; Tue, 8 Feb 2005 02:33:49 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j182Xnql028646; Tue, 8 Feb 2005 02:33:49 GMT Date: Tue, 8 Feb 2005 02:33:49 +0000 From: Ralf Baechle To: Manish Lachwani Cc: TheNop , linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite Message-ID: <20050208023349.GC15336@linux-mips.org> References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> <20050208015155.GB15336@linux-mips.org> <42081DA0.6070301@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42081DA0.6070301@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: 7198 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: 428 Lines: 11 On Mon, Feb 07, 2005 at 06:02:08PM -0800, Manish Lachwani wrote: > I completely agree. In any case, I dont think the CVS sources ever > supported SMP for Titan < 1.2, correct? No, that would have either meant taking a heavy performance penalty or hacking mm in very ugly ways. And due to the probably low numbers of the early silicon and the availability of later revisions the reason for such hacks was low anyway. Ralf From mlachwani@mvista.com Tue Feb 8 03:04:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 03:04:30 +0000 (GMT) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:23549 "EHLO hermes.mvista.com") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 03:04:14 +0000 Received: from mvista.com (prometheus.mvista.com [10.0.0.139]) by hermes.mvista.com (Postfix) with ESMTP id A58AF189DA; Mon, 7 Feb 2005 19:04:12 -0800 (PST) Message-ID: <42082C2C.5020703@mvista.com> Date: Mon, 07 Feb 2005 19:04:12 -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: TheNop , linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> <20050208015155.GB15336@linux-mips.org> <42081DA0.6070301@mvista.com> <20050208023349.GC15336@linux-mips.org> In-Reply-To: <20050208023349.GC15336@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: 7199 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: 709 Lines: 32 Ralf Baechle wrote: >On Mon, Feb 07, 2005 at 06:02:08PM -0800, Manish Lachwani wrote: > > > >>I completely agree. In any case, I dont think the CVS sources ever >>supported SMP for Titan < 1.2, correct? >> >> > >No, that would have either meant taking a heavy performance penalty or >hacking mm in very ugly ways. > How would I not know this? After all, I was the one who actually put this code together to get SMP to work on Titan 1.0 and 1.1, remember? ;) And you are right, there is no reason to put such hacks. Manish Lachwani >And due to the probably low numbers of >the early silicon and the availability of later revisions the reason >for such hacks was low anyway. > > Ralf > > > From TheNop@gmx.net Tue Feb 8 07:20:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 07:20:18 +0000 (GMT) Received: from pop.gmx.net ([IPv6:::ffff:213.165.64.20]:38052 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Tue, 8 Feb 2005 07:20:01 +0000 Received: (qmail invoked by alias); 08 Feb 2005 07:19:35 -0000 Received: from c178209.adsl.hansenet.de (EHLO [192.168.0.1]) (213.39.178.209) by mail.gmx.net (mp014) with SMTP; 08 Feb 2005 08:19:35 +0100 X-Authenticated: #947741 Message-ID: <42086846.9060709@gmx.net> Date: Tue, 08 Feb 2005 08:20:38 +0100 From: TheNop User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> <20050208015155.GB15336@linux-mips.org> <42081DA0.6070301@mvista.com> <20050208023349.GC15336@linux-mips.org> <42082C2C.5020703@mvista.com> In-Reply-To: <42082C2C.5020703@mvista.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: 7200 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: TheNop@gmx.net Precedence: bulk X-list: linux-mips Content-Length: 1411 Lines: 57 Hi, I'm sorry, but all the discussion on this thread did'n help me to solve my problem. Since more than a month I'm waitig to get a yosemite board with 1.2 version. This still stops my development, when I can't use the yosemite with 1.1 version. In another therad we discuss to create a patch (slowpath) for the titan version 1.1. the patch I apply to the the newer kernel sources (2.6.11.rc1) but, I have the same problems. So I think the problem could be the slowpath thing. Have anybody an idee how to figure out what could be the problem when I make "cp foo foo1" (foo is a lage file ~3,5 Mb)? Best regards TheNop Manish Lachwani wrote: > Ralf Baechle wrote: > >> On Mon, Feb 07, 2005 at 06:02:08PM -0800, Manish Lachwani wrote: >> >> >> >>> I completely agree. In any case, I dont think the CVS sources ever >>> supported SMP for Titan < 1.2, correct? >>> >> >> >> No, that would have either meant taking a heavy performance penalty or >> hacking mm in very ugly ways. > > > How would I not know this? After all, I was the one who actually put > this code together to get SMP to work on Titan 1.0 and 1.1, remember? > ;) And you are right, there is no reason to put such hacks. > > Manish Lachwani > > >> And due to the probably low numbers of >> the early silicon and the availability of later revisions the reason >> for such hacks was low anyway. >> >> Ralf >> >> >> > > > > From ibrahim@schenk.isar.de Tue Feb 8 07:30:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 07:30:47 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:33311 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 07:30:31 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j187URH32216; Tue, 8 Feb 2005 08:30:27 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j187URc12395; Tue, 8 Feb 2005 08:30:27 +0100 Message-ID: <42086A92.1020105@schenk.isar.de> Date: Tue, 08 Feb 2005 08:30:26 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Lachwani CC: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: Titan ethernet and little endian References: <42023C54.7060801@schenk.isar.de> <420269C1.6050701@mvista.com> <42071C29.3030507@schenk.isar.de> <4207A5AD.6090806@mvista.com> In-Reply-To: <4207A5AD.6090806@mvista.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7201 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 845 Lines: 42 Manish Lachwani wrote: > Rojhalat Ibrahim wrote: > >> Manish Lachwani wrote: >> >>> Hi ! >>> >>> So, have you got the titan to work in the LE mode? Are you using the >>> Yosemite board? Does this patch break BE? >>> >>> Please do let us know. >>> >>> Thanks >>> Manish Lachwani >>> >>> >> >> Hi! >> >> Yes I have got the titan work in LE mode. And yes I am using the >> Yosemite board. And no this patch does not break BE. I haven't >> actually tested that but all the changes I made are between >> #ifdef LITTLE_ENDIAN and #endif. >> >> Thanks >> Rojhalat Ibrahim >> >> > Ok, as long as the changes are in #ifdef. Although, your patch did not > indicate the "#ifdef LITTLE_ENDIAN" > > Thanks > Manish Lachwani > > > That's because the #ifdef was already there. The code inbetween was just not entirely correct. Thanks Rojhalat Ibrahim From Rishabh@soc-soft.com Tue Feb 8 09:46:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 09:47:14 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:25096 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 09:46:58 +0000 Received: from mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Tue, 08 Feb 2005 15:18:23 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50DC3.54885187" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Linux-mips port: HIGHMEM Address map Date: Tue, 8 Feb 2005 15:18:23 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C4C6E7F@soc-mail.soc-soft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux-mips port: HIGHMEM Address map Thread-Index: AcUNw1P4n2z9uvr5SQuKEdUGXPtCDg== 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: 7202 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: 11753 Lines: 384 This is a multi-part message in MIME format. ------_=_NextPart_001_01C50DC3.54885187 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =0D Guys I am trying to figure out the virtual address map of linux mips port for the HIGHMEM enabled kernel. I am unable to figure out from which virtual address map is the HIGHMEM Memory starts.=0D =0D I found in function mem_init() =0D high_memory =3D (KSEG1 - KSEG0) >> PAGE_SHIFT; =0D Also I have seen in many driver source codes that __virt_to_phys(high_memory) has been used, will that mean that virtual address for HIGHMEM is beginning from 0xa0000000.=0D =0D If that is so then if I want to relocate it to KSEG3 which I feel will be free how can I do it? I have my SDRAM mapped at 2 locations {virtual addresses} (0xa0000000 - 0xa3ffffff) and (0x80000000 - 0x83ffffff). Physical Address is (0x00000000 - 0x03ffffff). =0D I have also physical memory 0x20000000 - 0x23ffffff(physical address) to be used for HIGHMEM. =0D Regards, =0D Rishabh =0D 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_01C50DC3.54885187 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Guys I am trying to figure out the virtual address map= of linux mips port for the HIGHMEM enabled kernel.

I am unable to figure out from which virtual address map= is the HIGHMEM Memory starts.=

 

I found in function mem_init()

 

         =             &nb= sp;  high_memory =3D (KSEG1 – KSEG0) >>= PAGE_SHIFT;

 

Also I have seen in many driver source codes that __virt_to_phys(high_memory)= has been used, will that mean that virtual address for HIGHMEM is beginning from 0xa0000000.

 

If that is so then if I want to relocate it to KSEG3= which I feel will be free how can I do it?

I have my SDRAM mapped at 2 locations {virtual= addresses} (0xa0000000 – 0xa3ffffff) and (0x80000000 – 0x83ffffff). Physical Address= is (0x00000000 – 0x03ffffff).

 

I have also physical memory 0x20000000 – 0x23ffffff(physical address) to be used for= HIGHMEM.

 

Regards,

 

Rishabh

 

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_01C50DC3.54885187-- From Rishabh@soc-soft.com Tue Feb 8 09:51:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 09:51:26 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:29705 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 09:51:11 +0000 Received: from mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Tue, 08 Feb 2005 15:22:43 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50DC3.EF1F6B1D" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: FW: Linux-mips port: HIGHMEM Address map Date: Tue, 8 Feb 2005 15:22:43 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C4C6E86@soc-mail.soc-soft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux-mips port: HIGHMEM Address map Thread-Index: AcUNw1P4n2z9uvr5SQuKEdUGXPtCDgAAD6Cw 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: 7203 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: 13747 Lines: 433 This is a multi-part message in MIME format. ------_=_NextPart_001_01C50DC3.EF1F6B1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OOPS for the previous mail I guess I goofed up a little. Hi, =0D Guys I am trying to figure out the virtual address map of linux mips port for the HIGHMEM enabled kernel. I am unable to figure out from which virtual address map is the HIGHMEM Memory starts.=0D =0D I found in function mem_init() =0D highstart_pfn =3D (KSEG1 - KSEG0) >> PAGE_SHIFT; high_memory =3D (void *) __va(max_low_pfn * PAGE_SIZE); =0D Q1. Also I have seen in many driver source codes that virt_to_phys(high_memory) has been used, will that mean that virtual address for HIGHMEM is beginning from 0xa0000000.=0D =0D If that is so then if I want to relocate it to KSEG3 which I feel will be free how can I do it? I have my SDRAM mapped at 2 locations {virtual addresses} (0xa0000000 - 0xa3ffffff) and (0x80000000 - 0x83ffffff). Physical Address is (0x00000000 - 0x03ffffff). =0D I have also physical memory 0x20000000 - 0x23ffffff(physical address) to be used for HIGHMEM. =0D Q2. Why is highstart_pfn reinitialized in virtual address space? Regards, =0D Rishabh =0D 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_01C50DC3.EF1F6B1D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OOPS for the previous mail I guess I= goofed up a little.

Hi,

 

Guys I am trying to figure out the virtual address map= of linux mips port for the HIGHMEM enabled= kernel.

I am unable to figure out from which virtual address map= is the HIGHMEM Memory starts.

 

I found in function= mem_init()

 

         =             =    highstart_pfn =3D (KSEG1 - KSEG0) >>= PAGE_SHIFT;

         =             &nb= sp;  high_memory =3D (void *) __va(max_low_pfn * PAGE_SIZE);

 

Q1.      = Also I have seen in many driver source codes that virt_to_phys(high_memory) has been used, will that mean that virtual address for HIGHMEM is beginning from 0xa0000000.

 

If that is so then if I want to relocate it to KSEG3= which I feel will be free how can I do it?

I have my SDRAM mapped at 2 locations {virtual= addresses} (0xa0000000 – 0xa3ffffff) and (0x80000000 – 0x83ffffff).= Physical Address is (0x00000000 – 0x03ffffff).

 

I have also physical memory 0x20000000 – 0x23ffffff(physical address) to be used for= HIGHMEM.

 

Q2.       Why is highstart_pfn reinitialized in virtual= address space?

Regards,

 

Rishabh

 

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_01C50DC3.EF1F6B1D-- From ibrahim@schenk.isar.de Tue Feb 8 09:57:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 09:57:32 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:65311 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 09:57:16 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j189vEH00649; Tue, 8 Feb 2005 10:57:14 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j189vEc13328; Tue, 8 Feb 2005 10:57:14 +0100 Message-ID: <42088CFA.6090605@schenk.isar.de> Date: Tue, 08 Feb 2005 10:57:14 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> In-Reply-To: <20050208001742.GA15336@linux-mips.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7204 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 1780 Lines: 55 Ralf Baechle wrote: > > Blowing away the entire S-cache is extreme overkill. We really want to > avoid this if possible as it'll have serious performance impact. As for > the RM9000 that means we have a struct page pointer, therefore we know > the physical address of the page and can perform a selective flush on the > second level cache. See below for a patch which tries that. > > Obviously this one only tries to optimize performance a bit further but > doesn't really solve the remaining problem. > > Ralf > > Index: arch/mips/mm/c-r4k.c > =================================================================== > RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v > retrieving revision 1.101 > diff -u -r1.101 c-r4k.c > --- arch/mips/mm/c-r4k.c 7 Feb 2005 21:53:39 -0000 1.101 > +++ arch/mips/mm/c-r4k.c 8 Feb 2005 00:18:17 -0000 > @@ -566,9 +566,21 @@ > > if (!cpu_has_ic_fills_f_dc) { > unsigned long addr = (unsigned long) page_address(page); > - r4k_blast_dcache_page(addr); > - if (!cpu_icache_snoops_remote_store) > - r4k_blast_scache_page(addr); > + > + if (addr) > + r4k_blast_dcache_page(addr); > + else > + r4k_blast_dcache(); > + > + if (!cpu_icache_snoops_remote_store) { > + if (addr) > + r4k_blast_scache_page(addr); > + else { > + addr = page_to_pfn(page) << PAGE_SHIFT; > + addr = CKSEG + (addr & ~((1UL << 24) - 1)); > + r4k_blast_scache_page_indexed(addr); > + } > + } > ClearPageDcacheDirty(page); > } > > I presume CKSEG is CKSEG0 in the above patch. With that it works about the same as before. So do you have any clue what the problem behind all that really is? Furthermore I still have all those "Illegal instruction" and "Segmentation fault" messages that shouldn't be there. Thanks Rojhalat Ibrahim From ralf@linux-mips.org Tue Feb 8 10:59:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 10:59:21 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:39137 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 10:59:06 +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 j18As13W008438; Tue, 8 Feb 2005 10:54:01 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j18As1mN008437; Tue, 8 Feb 2005 10:54:01 GMT Date: Tue, 8 Feb 2005 10:54:01 +0000 From: Ralf Baechle To: TheNop Cc: linux-mips@linux-mips.org Subject: Re: Kernel crash on yosemite Message-ID: <20050208105401.GB6131@linux-mips.org> References: <4207F163.4010605@gmx.net> <20050208013000.GA6131@linux-mips.org> <42081A2C.5060503@mvista.com> <20050208015155.GB15336@linux-mips.org> <42081DA0.6070301@mvista.com> <20050208023349.GC15336@linux-mips.org> <42082C2C.5020703@mvista.com> <42086846.9060709@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42086846.9060709@gmx.net> 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: 7205 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: 991 Lines: 23 On Tue, Feb 08, 2005 at 08:20:38AM +0100, TheNop wrote: > I'm sorry, but all the discussion on this thread did'n help me to solve > my problem. Since more than a month I'm waitig to get a yosemite board > with 1.2 version. This still stops my development, when I can't use the > yosemite with 1.1 version. > > In another therad we discuss to create a patch (slowpath) for the titan > version 1.1. the patch I apply to the the newer kernel sources > (2.6.11.rc1) but, I have the same problems. So I think the problem could > be the slowpath thing. > > Have anybody an idee how to figure out what could be the problem when I > make "cp foo foo1" (foo is a lage file ~3,5 Mb)? A network driver bug in the 2.6 Titan driver which I recently fixes was that the allocated receive and transmit rings were allocated overlapping which was causing havoc. Yosemite w/ Titan 1.1 was suffering from unexplained system freezes for me; a more recent board with Titan 1.2 is very stable. Ralf From eckhardt@satorlaser.com Tue Feb 8 14:11:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 14:12:01 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:54522 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 14:11:45 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CyW5c-0005H3-00; Tue, 08 Feb 2005 15:11:40 +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 1CyW5c-0000xg-00; Tue, 08 Feb 2005 15:11:40 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: [PATCH] au1100fb.c ported from 2.4 to 2.6 Date: Tue, 8 Feb 2005 15:14:07 +0100 User-Agent: KMail/1.7.1 Cc: Christian References: <1105523407.5654.18.camel@absolute.ascensit.com> In-Reply-To: <1105523407.5654.18.camel@absolute.ascensit.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_wkMCCPVzb3xx30p" Message-Id: <200502081514.08186.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: 7207 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: 10664 Lines: 372 --Boundary-00=_wkMCCPVzb3xx30p Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Another two suggestions: - you hard-coded the used display in au1100fb.{h,c} with #ifdef CONFIG_WWPC. There is another option already used in arch/mips/au1000/common/setup.c, and that is to append the necessary lines to the kernel commandline if no conflicting arguments are present. - I have removed the comments that say to which field a constant belongs and instead converted au1100fb.h to use new-style initialisers which is just easier to not get wrong. I also added parameters for my display and replaced the #define for uint32. The new file is attached as whole, I didn't know against what to diff it... Could you merge the file and resend the patch? I hope it will get committed then. Uli --Boundary-00=_wkMCCPVzb3xx30p Content-Type: text/x-chdr; charset="iso-8859-1"; name="au1100fb.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="au1100fb.h" /* * BRIEF MODULE DESCRIPTION * Hardware definitions for the Au1100 LCD controller * * Copyright 2002 MontaVista Software * Copyright 2002 Alchemy Semiconductor * Author: Alchemy Semiconductor, MontaVista Software * * 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. */ #ifndef _AU1100LCD_H #define _AU1100LCD_H /********************************************************************/ typedef volatile struct { u32 lcd_control; u32 lcd_intstatus; u32 lcd_intenable; u32 lcd_horztiming; u32 lcd_verttiming; u32 lcd_clkcontrol; u32 lcd_dmaaddr0; u32 lcd_dmaaddr1; u32 lcd_words; u32 lcd_pwmdiv; u32 lcd_pwmhi; u32 reserved[(0x0400-0x002C)/4]; u32 lcd_pallettebase[256]; } AU1100_LCD; /********************************************************************/ #define AU1100_LCD_ADDR 0xB5000000 /* * Register bit definitions */ /* lcd_control */ #define LCD_CONTROL_SBB_1 (0<<21) #define LCD_CONTROL_SBB_2 (1<<21) #define LCD_CONTROL_SBB_3 (2<<21) #define LCD_CONTROL_SBB_4 (3<<21) #define LCD_CONTROL_SBPPF (7<<18) #define LCD_CONTROL_SBPPF_655 (0<<18) #define LCD_CONTROL_SBPPF_565 (1<<18) #define LCD_CONTROL_SBPPF_556 (2<<18) #define LCD_CONTROL_SBPPF_1555 (3<<18) #define LCD_CONTROL_SBPPF_5551 (4<<18) #define LCD_CONTROL_WP (1<<17) #define LCD_CONTROL_WD (1<<16) #define LCD_CONTROL_C (1<<15) #define LCD_CONTROL_SM (3<<13) #define LCD_CONTROL_SM_0 (0<<13) #define LCD_CONTROL_SM_90 (1<<13) #define LCD_CONTROL_SM_180 (2<<13) #define LCD_CONTROL_SM_270 (3<<13) #define LCD_CONTROL_DB (1<<12) #define LCD_CONTROL_CCO (1<<11) #define LCD_CONTROL_DP (1<<10) #define LCD_CONTROL_PO (3<<8) #define LCD_CONTROL_PO_00 (0<<8) #define LCD_CONTROL_PO_01 (1<<8) #define LCD_CONTROL_PO_10 (2<<8) #define LCD_CONTROL_PO_11 (3<<8) #define LCD_CONTROL_MPI (1<<7) #define LCD_CONTROL_PT (1<<6) #define LCD_CONTROL_PC (1<<5) #define LCD_CONTROL_BPP (7<<1) #define LCD_CONTROL_BPP_1 (0<<1) #define LCD_CONTROL_BPP_2 (1<<1) #define LCD_CONTROL_BPP_4 (2<<1) #define LCD_CONTROL_BPP_8 (3<<1) #define LCD_CONTROL_BPP_12 (4<<1) #define LCD_CONTROL_BPP_16 (5<<1) #define LCD_CONTROL_GO (1<<0) /* lcd_intstatus, lcd_intenable */ #define LCD_INT_SD (1<<7) #define LCD_INT_OF (1<<6) #define LCD_INT_UF (1<<5) #define LCD_INT_SA (1<<3) #define LCD_INT_SS (1<<2) #define LCD_INT_S1 (1<<1) #define LCD_INT_S0 (1<<0) /* lcd_horztiming */ #define LCD_HORZTIMING_HN2 (255<<24) #define LCD_HORZTIMING_HN2_N(N) (((N)-1)<<24) #define LCD_HORZTIMING_HN1 (255<<16) #define LCD_HORZTIMING_HN1_N(N) (((N)-1)<<16) #define LCD_HORZTIMING_HPW (63<<10) #define LCD_HORZTIMING_HPW_N(N) (((N)-1)<<10) #define LCD_HORZTIMING_PPL (1023<<0) #define LCD_HORZTIMING_PPL_N(N) (((N)-1)<<0) /* lcd_verttiming */ #define LCD_VERTTIMING_VN2 (255<<24) #define LCD_VERTTIMING_VN2_N(N) (((N)-1)<<24) #define LCD_VERTTIMING_VN1 (255<<16) #define LCD_VERTTIMING_VN1_N(N) (((N)-1)<<16) #define LCD_VERTTIMING_VPW (63<<10) #define LCD_VERTTIMING_VPW_N(N) (((N)-1)<<10) #define LCD_VERTTIMING_LPP (1023<<0) #define LCD_VERTTIMING_LPP_N(N) (((N)-1)<<0) /* lcd_clkcontrol */ #define LCD_CLKCONTROL_IB (1<<18) #define LCD_CLKCONTROL_IC (1<<17) #define LCD_CLKCONTROL_IH (1<<16) #define LCD_CLKCONTROL_IV (1<<15) #define LCD_CLKCONTROL_BF (31<<10) #define LCD_CLKCONTROL_BF_N(N) (((N)-1)<<10) #define LCD_CLKCONTROL_PCD (1023<<0) #define LCD_CLKCONTROL_PCD_N(N) ((N)<<0) /* lcd_pwmdiv */ #define LCD_PWMDIV_EN (1<<12) #define LCD_PWMDIV_PWMDIV (2047<<0) #define LCD_PWMDIV_PWMDIV_N(N) (((N)-1)<<0) /* lcd_pwmhi */ #define LCD_PWMHI_PWMHI1 (2047<<12) #define LCD_PWMHI_PWMHI1_N(N) ((N)<<12) #define LCD_PWMHI_PWMHI0 (2047<<0) #define LCD_PWMHI_PWMHI0_N(N) ((N)<<0) /* lcd_pallettebase - MONOCHROME */ #define LCD_PALLETTE_MONO_MI (15<<0) #define LCD_PALLETTE_MONO_MI_N(N) ((N)<<0) /* lcd_pallettebase - COLOR */ #define LCD_PALLETTE_COLOR_BI (15<<8) #define LCD_PALLETTE_COLOR_BI_N(N) ((N)<<8) #define LCD_PALLETTE_COLOR_GI (15<<4) #define LCD_PALLETTE_COLOR_GI_N(N) ((N)<<4) #define LCD_PALLETTE_COLOR_RI (15<<0) #define LCD_PALLETTE_COLOR_RI_N(N) ((N)<<0) /* lcd_palletebase - COLOR TFT PALLETIZED */ #define LCD_PALLETTE_TFT_DC (65535<<0) #define LCD_PALLETTE_TFT_DC_N(N) ((N)<<0) /********************************************************************/ struct known_lcd_panels { uint32 xres; uint32 yres; uint32 bpp; unsigned char panel_name[256]; uint32 mode_control; uint32 mode_horztiming; uint32 mode_verttiming; uint32 mode_clkcontrol; uint32 mode_pwmdiv; uint32 mode_pwmhi; uint32 mode_toyclksrc; uint32 mode_backlight; }; #if defined(__BIG_ENDIAN) # define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_11 #else # define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_00 #endif /* * The fb driver assumes that AUX PLL is at 48MHz. That can * cover up to 800x600 resolution; if you need higher resolution, * you should modify the driver as needed, not just this structure. */ struct known_lcd_panels panels[] = { #ifdef CONFIG_WWPC { /* just the standard LCD */ .xres = 240, .yres = 320, .bpp = 16, .panel_name = "WWPC LCD", .mode_control = 0x0006806A, .mode_horztiming = 0x0A1010EF, .mode_verttiming = 0x0301013F, .mode_clkcontrol = 0x00018001, .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = 0, /* not used */ .mode_backlight = 0 /* not used */ } #else { /* Pb1100 LCDA: Sharp 320x240 TFT panel */ .xres = 320, .yres = 240, .bpp = 16, .panel_name = "Sharp_320x240_16", .mode_control = ( LCD_CONTROL_SBPPF_565 | LCD_CONTROL_C | LCD_CONTROL_SM_0 | LCD_DEFAULT_PIX_FORMAT | LCD_CONTROL_PT | LCD_CONTROL_PC | LCD_CONTROL_BPP_16 ), .mode_horztiming = ( LCD_HORZTIMING_HN2_N(8) | LCD_HORZTIMING_HN1_N(60) | LCD_HORZTIMING_HPW_N(12) | LCD_HORZTIMING_PPL_N(320) ), .mode_verttiming = ( LCD_VERTTIMING_VN2_N(5) | LCD_VERTTIMING_VN1_N(17) | LCD_VERTTIMING_VPW_N(1) | LCD_VERTTIMING_LPP_N(240) ), .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(1), .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<7) | (1<<6) | (1<<5)), .mode_backlight = 6 }, { /* Hitachi SP14Q005 and possibly others */ .xres = 320, .yres = 240, .bpp = 4, .panel_name = "Hitachi_SP14Qxxx", .mode_control = ( LCD_CONTROL_C | LCD_CONTROL_BPP_4 ), .mode_horztiming = ( LCD_HORZTIMING_HN2_N(1) | LCD_HORZTIMING_HN1_N(1) | LCD_HORZTIMING_HPW_N(1) | LCD_HORZTIMING_PPL_N(320) ), .mode_verttiming = ( LCD_VERTTIMING_VN2_N(1) | LCD_VERTTIMING_VN1_N(1) | LCD_VERTTIMING_VPW_N(1) | LCD_VERTTIMING_LPP_N(240) ), .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(4), .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<27) | (1<<26) | (1<<25) | (1<<7) | (1<<6) | (1<<5)), .mode_backlight = 6 }, { /* Pb1100 LCDC 640x480 TFT panel */ .xres = 640, .yres = 480, .bpp = 16, .panel_name = "Generic_640x480_16", .mode_control = 0x004806a | LCD_DEFAULT_PIX_FORMAT, .mode_horztiming = 0x3434d67f, .mode_verttiming = 0x0e0e39df, .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(1), .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<7) | (1<<6) | (0<<5)), .mode_backlight = 7 }, { /* Pb1100 LCDB 640x480 PrimeView TFT panel */ .xres = 640, .yres = 480, .bpp = 16, .panel_name = "PrimeView_640x480_16", .mode_control = 0x0004886a | LCD_DEFAULT_PIX_FORMAT, .mode_horztiming = 0x0e4bfe7f, .mode_verttiming = 0x210805df, .mode_clkcontrol = 0x00038001, .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<7) | (1<<6) | (0<<5)), .mode_backlight = 7 }, { /* Pb1100 800x600x16bpp NEON CRT */ .xres = 800, .yres = 600, .bpp = 16, .panel_name = "NEON_800x600_16", .mode_control = 0x0004886A | LCD_DEFAULT_PIX_FORMAT, .mode_horztiming = 0x005AFF1F, .mode_verttiming = 0x16000E57, .mode_clkcontrol = 0x00020000, .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<7) | (1<<6) | (0<<5)), .mode_backlight = 7 }, { /* Pb1100 640x480x16bpp NEON CRT */ .xres = 640, .yres = 480, .bpp = 16, .panel_name = "NEON_640x480_16", .mode_control = 0x0004886A | LCD_DEFAULT_PIX_FORMAT, .mode_horztiming = 0x0052E27F, .mode_verttiming = 0x18000DDF, .mode_clkcontrol = 0x00020000, .mode_pwmdiv = 0, .mode_pwmhi = 0, .mode_toyclksrc = ((1<<7) | (1<<6) | (0<<5)), .mode_backlight = 7 }, #endif }; #endif /* _AU1100LCD_H */ --Boundary-00=_wkMCCPVzb3xx30p-- From pe1rxq@amsat.org Tue Feb 8 17:13:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Feb 2005 17:13:45 +0000 (GMT) Received: from amsfep12-int.chello.nl ([IPv6:::ffff:213.46.243.17]:47656 "EHLO amsfep12-int.chello.nl") by linux-mips.org with ESMTP id ; Tue, 8 Feb 2005 17:13:25 +0000 Received: from [127.0.0.1] (really [62.195.248.222]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050208171318.JKET21348.amsfep12-int.chello.nl@[127.0.0.1]>; Tue, 8 Feb 2005 18:13:18 +0100 Message-ID: <4208F347.4050304@amsat.org> Date: Tue, 08 Feb 2005 18:13:43 +0100 From: Jeroen Vreeken User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-2?Q?Tom_Vr=E1na?= , linux-mips@linux-mips.org Subject: Re: ADM5120: time.c issues ? References: <4207C71F.7050204@voda.cz> In-Reply-To: <4207C71F.7050204@voda.cz> Content-Type: text/plain; charset=ISO-8859-2; 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: 7208 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: pe1rxq@amsat.org Precedence: bulk X-list: linux-mips Content-Length: 647 Lines: 21 Tom Vrána wrote: > Using jeroens time.c the system boots painfully slow, sort of loops > int the beginning and the finally freezes on the FPU emulator... any > suggestions ? > The 2.6.10 kernels I compiled don't seem slow to me.. So there is some difference between those two... (Is there a reason you need a 2.4 kernel instead of 2.6?) > > ttyS28 at 0x03f8 (irq = 4) is a 16450 > ttyS29 at 0x02f8 (irq = 3) is a 16450 > ttyS30 at 0x03e8 (irq = 4) is a 16450 This might have something to do with it... I don't think this serial driver should be used. There might be more unneeded stuff in your kernel that might do funny things. Jeroen From ralf@linux-mips.org Wed Feb 9 00:11:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 00:12:04 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:24038 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 00:11: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 j1906f6x018620; Wed, 9 Feb 2005 00:06:41 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1906eBQ018619; Wed, 9 Feb 2005 00:06:40 GMT Date: Wed, 9 Feb 2005 00:06:40 +0000 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050209000640.GA10651@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42088CFA.6090605@schenk.isar.de> 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: 7210 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: 655 Lines: 16 On Tue, Feb 08, 2005 at 10:57:14AM +0100, Rojhalat Ibrahim wrote: > I presume CKSEG is CKSEG0 in the above patch. With that it works > about the same as before. So do you have any clue what the problem > behind all that really is? Furthermore I still have all those > "Illegal instruction" and "Segmentation fault" messages that > shouldn't be there. Sorry, yes I indeed meant CKSEG0. And this version of the patch really was only meant to optimize the large performance impact your previous patch had; it wasn't meant to fix anything beyond that. As I can't replicate your configuration I'm still starring at the code to find what's wrong ... Ralf From ibrahim@schenk.isar.de Wed Feb 9 08:06:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 08:07:11 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:42787 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 08:06:53 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1986hH08172; Wed, 9 Feb 2005 09:06:43 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1986gc19514; Wed, 9 Feb 2005 09:06:43 +0100 Message-ID: <4209C492.4050201@schenk.isar.de> Date: Wed, 09 Feb 2005 09:06:42 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> <20050209000640.GA10651@linux-mips.org> In-Reply-To: <20050209000640.GA10651@linux-mips.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7211 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Feb 08, 2005 at 10:57:14AM +0100, Rojhalat Ibrahim wrote: > > >>I presume CKSEG is CKSEG0 in the above patch. With that it works >>about the same as before. So do you have any clue what the problem >>behind all that really is? Furthermore I still have all those >>"Illegal instruction" and "Segmentation fault" messages that >>shouldn't be there. > > > Sorry, yes I indeed meant CKSEG0. And this version of the patch really was > only meant to optimize the large performance impact your previous patch > had; it wasn't meant to fix anything beyond that. > > As I can't replicate your configuration I'm still starring at the code to > find what's wrong ... > > Ralf > Ok, thanks. If I can try anything that might help track down the problem, please let me know. Rojhalat From anemo@mba.ocn.ne.jp Wed Feb 9 09:49:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 09:50:08 +0000 (GMT) Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:2312 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Wed, 9 Feb 2005 09:49:53 +0000 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 9 Feb 2005 09:49:51 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 3DA2F239E2C; Wed, 9 Feb 2005 18:49:48 +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 j199nlRm056467; Wed, 9 Feb 2005 18:49:48 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 09 Feb 2005 18:49:47 +0900 (JST) Message-Id: <20050209.184947.30439119.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: copy_from_user_page/copy_to_user_page 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: 7212 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 Yet another dcache aliasing problem. Since access_process_vm() in kernel 2.6 does not call flush_cache_page(), it seems copy_to_user_page()/copy_from_user_page() should flush data cache to resolve aliasing. Without this fix, gdb will not work correctly. Could you apply? diff -u linux-mips/include/asm-mips/cacheflush.h linux/include/asm-mips/cacheflush.h --- linux-mips/include/asm-mips/cacheflush.h 2004-08-14 19:55:59.000000000 +0900 +++ linux/include/asm-mips/cacheflush.h 2005-02-09 17:55:39.402702039 +0900 @@ -56,11 +56,17 @@ #define copy_to_user_page(vma, page, vaddr, dst, src, len) \ do { \ + if (cpu_has_dc_aliases) \ + flush_cache_page(vma, vaddr); \ memcpy(dst, (void *) src, len); \ flush_icache_page(vma, page); \ } while (0) #define copy_from_user_page(vma, page, vaddr, dst, src, len) \ - memcpy(dst, src, len) +do { \ + if (cpu_has_dc_aliases) \ + flush_cache_page(vma, vaddr); \ + memcpy(dst, src, len); \ +} while (0) extern void (*flush_cache_sigtramp)(unsigned long addr); extern void (*flush_icache_all)(void); --- Atsushi Nemoto From ralf@linux-mips.org Wed Feb 9 12:51:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 12:51:25 +0000 (GMT) Received: from p3EE07C4A.dip.t-dialin.net ([IPv6:::ffff:62.224.124.74]:53276 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 12:51:10 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j19Cp9F2027931; Wed, 9 Feb 2005 13:51:09 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j19Cp5vQ027930; Wed, 9 Feb 2005 13:51:05 +0100 Date: Wed, 9 Feb 2005 13:51:05 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: copy_from_user_page/copy_to_user_page fix Message-ID: <20050209125105.GA27875@linux-mips.org> References: <20050209.184947.30439119.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209.184947.30439119.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: 7213 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 09, 2005 at 06:49:47PM +0900, Atsushi Nemoto wrote: > Yet another dcache aliasing problem. > > Since access_process_vm() in kernel 2.6 does not call > flush_cache_page(), it seems copy_to_user_page()/copy_from_user_page() > should flush data cache to resolve aliasing. > > Without this fix, gdb will not work correctly. Could you apply? I'm going to apply this because it's a correct fix; the temporary mapping strategy as we've discussed for the dup_mmap problem would be preferable. Ralf From anemo@mba.ocn.ne.jp Wed Feb 9 13:51:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 13:51:59 +0000 (GMT) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:11249 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Wed, 9 Feb 2005 13:51:44 +0000 Received: from localhost (p6066-ipad203funabasi.chiba.ocn.ne.jp [222.146.85.66]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 9C39D2606; Wed, 9 Feb 2005 22:51:41 +0900 (JST) Date: Wed, 09 Feb 2005 22:52:56 +0900 (JST) Message-Id: <20050209.225256.92587183.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: copy_from_user_page/copy_to_user_page fix From: Atsushi Nemoto In-Reply-To: <20050209125105.GA27875@linux-mips.org> References: <20050209.184947.30439119.nemoto@toshiba-tops.co.jp> <20050209125105.GA27875@linux-mips.org> 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: 7214 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 >>>>> On Wed, 9 Feb 2005 13:51:05 +0100, Ralf Baechle said: ralf> I'm going to apply this because it's a correct fix; the ralf> temporary mapping strategy as we've discussed for the dup_mmap ralf> problem would be preferable. Thank you. I agree that the temporary mapping will be more efficient though I chose a simple fix. I suppose a performance requirement for ptrace() would be less than the dup_mmap (fork()). --- Atsushi Nemoto From ibrahim@schenk.isar.de Wed Feb 9 15:41:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 15:42:12 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:23077 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 15:41:56 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j19FfYH11240; Wed, 9 Feb 2005 16:41:34 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j19FfXc23637; Wed, 9 Feb 2005 16:41:33 +0100 Message-ID: <420A2F2D.8050404@schenk.isar.de> Date: Wed, 09 Feb 2005 16:41:33 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> In-Reply-To: <42088CFA.6090605@schenk.isar.de> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7215 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Rojhalat Ibrahim wrote: > Furthermore I still have all those > "Illegal instruction" and "Segmentation fault" messages that > shouldn't be there. > Those messages actually go away when I do not define cpu_has_64bit_gp_regs, which is strange because the RM9000 definitely has 64bit gp regs. Any ideas? Thanks Rojhalat Ibrahim From ralf@linux-mips.org Wed Feb 9 18:10:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 18:11:04 +0000 (GMT) Received: from p3EE07C4A.dip.t-dialin.net ([IPv6:::ffff:62.224.124.74]:285 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 18:10:45 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j19IAinD005862; Wed, 9 Feb 2005 19:10:44 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j19IAiW8005861; Wed, 9 Feb 2005 19:10:44 +0100 Date: Wed, 9 Feb 2005 19:10:44 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: copy_from_user_page/copy_to_user_page fix Message-ID: <20050209181044.GA5740@linux-mips.org> References: <20050209.184947.30439119.nemoto@toshiba-tops.co.jp> <20050209125105.GA27875@linux-mips.org> <20050209.225256.92587183.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209.225256.92587183.anemo@mba.ocn.ne.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: 7216 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 09, 2005 at 10:52:56PM +0900, Atsushi Nemoto wrote: > ralf> I'm going to apply this because it's a correct fix; the > ralf> temporary mapping strategy as we've discussed for the dup_mmap > ralf> problem would be preferable. > > Thank you. I agree that the temporary mapping will be more efficient > though I chose a simple fix. I suppose a performance requirement for > ptrace() would be less than the dup_mmap (fork()). People have come up with creative abuses for ptrace which actually make it a performance critical path. Especially UML should be mentioned in this cathegory. And we're talkign about a few thousand cycles differences per ptrace invocation. Ralf From ralf@linux-mips.org Wed Feb 9 18:14:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Feb 2005 18:15:00 +0000 (GMT) Received: from p3EE07C4A.dip.t-dialin.net ([IPv6:::ffff:62.224.124.74]:5149 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 9 Feb 2005 18:14:46 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j19IEjFu005962; Wed, 9 Feb 2005 19:14:45 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j19IEib7005961; Wed, 9 Feb 2005 19:14:44 +0100 Date: Wed, 9 Feb 2005 19:14:44 +0100 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050209181444.GB5740@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> <420A2F2D.8050404@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420A2F2D.8050404@schenk.isar.de> 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: 7217 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 09, 2005 at 04:41:33PM +0100, Rojhalat Ibrahim wrote: > Those messages actually go away when I do not > define cpu_has_64bit_gp_regs, which is strange > because the RM9000 definitely has 64bit gp regs. > Any ideas? cpu_has_64bit_gp_regs is meant to indicate "CPU has 64-bit registers and it's actually safe to use them". This is why it's defined as 0 for all 32-bit kernels where an interrupt would corrupt the upper 32-bits which we don't save during any kind of exception. Ralf From guy.streeter@gmail.com Thu Feb 10 00:05:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 00:06:10 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.192]:42053 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 00:05:53 +0000 Received: by rproxy.gmail.com with SMTP id 40so166995rnz for ; Wed, 09 Feb 2005 16:05: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=pRKAdqz70H4r2quUY1f7MFTHJwjxZ1Ab6QaxZUH/8GbQCJPUcSa+j5ikosMxaoF+Lr66X+qRDlGOVl/D75jz/5MY2IagXr1ZsO6PClt715ePexqy6ykTePfdf8gojNku5ZkBMkcGVmnP84BjIIj/CobVTKQoGCP/qjVK4INWDok= Received: by 10.38.179.61 with SMTP id b61mr26672rnf; Wed, 09 Feb 2005 16:05:40 -0800 (PST) Received: by 10.38.179.17 with HTTP; Wed, 9 Feb 2005 16:05:40 -0800 (PST) Message-ID: <52dd17640502091605ba90f08@mail.gmail.com> Date: Wed, 9 Feb 2005 18:05:40 -0600 From: Guy Streeter Reply-To: Guy Streeter To: linux-mips Subject: interrupt problems with USB on malta 4kc 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: 7219 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: guy.streeter@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 3097 Lines: 78 I am trying to use USB devices on a 4kc malta board. I see no problems from USB unless a device (any device, apparently) is plugged in to a USB port. After that, interrupts stop working (for everything, not just USB, as far as I can tell). I jave seen this on 2.6.8.1, 2.6.10, and 2.6.11-rc2. I have traced this down to the point where the mips_pcibios_iack routine sometimes gets an irq value of 0xFF. I put in a BUG_ON that condition, and it looks to me as though interrupts are happening during the interrupt service routine. I am attaching the backtrace below. Does this look familiar to anyone? thanks, --Guy backtrace from mips_pcibios_iack() when irq == 0xFF (2.6.10 kernel from mips.org CVS): Call Trace: [<801008a8>] mipsIRQ+0x128/0x180 [<8023b398>] hcd_submit_urb+0x0/0x898 [<80126ba0>] do_softirq+0x8c/0xb8 [<801069ac>] timer_interrupt+0x128/0x270 [<80126a20>] __do_softirq+0x50/0x144 [<80126ba0>] do_softirq+0x8c/0xb8 [<80106b34>] ll_timer_interrupt+0x40/0x4c [<80100890>] mipsIRQ+0x110/0x180 [<80100f64>] malta_hw0_irqdispatch+0x1e4/0x20c [<8023b398>] hcd_submit_urb+0x0/0x898 [<801008a8>] mipsIRQ+0x128/0x180 [<80102040>] handle_bp_int+0x18/0x38 [<802b70e8>] skb_read_and_csum_bits+0x0/0xb4 [<8012b3b0>] upate_process_times+0xe4/0x14c [<80100f64>] malta_hw0_irqdispatch+0x1e4/0x20c [<8023b398>] hcd_submit_urb+0x0/0x898 [<80106b34>] ll_timer_interrupt+0x40/0x4c [<801008a8>] mipsIRQ+0x128/0x180 [<80106b34>] ll_timer_interrupt+0x40/0x4c [<80100f80>] malta_hw0_irqdispatch+0x200/0x20c [<801008a8>] mipsIRQ+0x128/0x180 [<80100f64>] malta_hw0_irqdispatch+0x1e4/0x20c [<8023b398>] hcd_submit_urb+0x0/0x898 [<8014be14>] cache_fee_debugcheck+0x258/0x2d4 [<8014bde4>] cache_free_debugcheck+0x228/0x2d [<801008a8>] mipsIRQ+0x128/0x180 [<80102040>] handle_bp_int+0x18/0x38 [<8024ef48>] kfree_skbmem+0x14/0x30 [<80100f64>] malta_hw0_irqdispatch+0x1e4/0x20c [<8023b398>] hcd_submit_urb+0x0/0x898 [<8011cef4>] tr_to_wake_up+0x84/0x178 [<801008a8>] mipsIRQ+0x128/0x180 [<80100f80>] malta_hw0_irqdispatch+0x200/0x20c [<8011dcf8>] __wake_up_common+0x68/0xb8 [<8024e358>] alloc_skb+0x58/0xf4 [<801008a8>] mipsIRQ+0x128/0x180 [<80240000>] usb_rmove_sysfs_dev_files+0xac/0xe0 [<80100f64>] malta_hw0_rqdispatch+0x1e4/0x20c [<8023b398>] hcd_submit_urb+0x0/0x898 [<801008a8>] mipsIRQ+0x128/0x180 [] init_stall_timer+0x50/0x60 [uhci_hcd] [<80102040>] handle_bp_int+0x18/0x38 [<8011cef4>] try_to_wake_up+0x84/0x178 [<80100f64>] malta_hw0_irqdispatch+0x1e4/0x0c [<8023b398>] hcd_submit_urb+0x0/0x898 [<801008a8>] mipsIRQ+0x128/0x180 [<80100f80>] malta_hw0_irqdispatch+0x2000x20c [<80126ba0>] do_softirq+0x8c/0xb8 [<80106b34>] ll_timer_interrupt+0x40/0x4c [<801008a8>] mipsIRQ+0x128/0x180 [<80100890>] mipsIRQ+0x110/0x180 [<801011ec>] r4k_wait+0x0/0xc [<8023b398>] hcd_submit_urb+0x0/0x898 [<80102c44>] cpu_idle+0x3c/0x60 [<801011f0>] r4k_wait+0x4/0xc [<8010041c>] rest_init+0x1c/0x28 [<80122064>] printk+0x2c/0x38 [<8032d96c>] start_kernel+0x1bc/0x264 [<8032d95c>] start_kernel+0x1ac/0x264 [<8032d30c>] unknown_bootoption+0x0/0x304 From maillist@jg555.com Thu Feb 10 04:49:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 04:49:24 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:4799 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 04:49:08 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN jim, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Wed, 09 Feb 2005 20:45:45 -0800 id 00008470.420AE6F9.00000CB3 Message-ID: <420AE7B9.6070202@jg555.com> Date: Wed, 09 Feb 2005 20:48:57 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Linux from Scratch 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: 7220 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: 653 Lines: 19 I have updated my RaQ2 build for Linux from Scratch to most of the latest packages for the RaQ2. A question was raised by some other memebers of the Linux from Scratch group, that frankly I didn't have the answers for. I appreciate your feedback on these questions. 1 - Will the build method I have currently work with any MIPS processor based machine, with the exception of the bootloader? 2 - Is there a bootloader for MIPS that will work on every machine, or is different for every MIPS based machine's firmware? If so any examples out there how to implement? Thank you for your time and assistance -- ---- Jim Gifford maillist@jg555.com From ibrahim@schenk.isar.de Thu Feb 10 08:43:53 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 08:44:09 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:36136 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 08:43:53 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1A8hCH17425; Thu, 10 Feb 2005 09:43:12 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1A8hBc29457; Thu, 10 Feb 2005 09:43:12 +0100 Message-ID: <420B1E9F.1060206@schenk.isar.de> Date: Thu, 10 Feb 2005 09:43:11 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Lachwani CC: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: Titan ethernet and little endian References: <42023C54.7060801@schenk.isar.de> <420269C1.6050701@mvista.com> <42071C29.3030507@schenk.isar.de> <4207A5AD.6090806@mvista.com> In-Reply-To: <4207A5AD.6090806@mvista.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7221 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 853 Lines: 43 Manish Lachwani wrote: > Rojhalat Ibrahim wrote: > >> Manish Lachwani wrote: >> >>> Hi ! >>> >>> So, have you got the titan to work in the LE mode? Are you using the >>> Yosemite board? Does this patch break BE? >>> >>> Please do let us know. >>> >>> Thanks >>> Manish Lachwani >>> >>> >> >> Hi! >> >> Yes I have got the titan work in LE mode. And yes I am using the >> Yosemite board. And no this patch does not break BE. I haven't >> actually tested that but all the changes I made are between >> #ifdef LITTLE_ENDIAN and #endif. >> >> Thanks >> Rojhalat Ibrahim >> >> > Ok, as long as the changes are in #ifdef. Although, your patch did not > indicate the "#ifdef LITTLE_ENDIAN" > > Thanks > Manish Lachwani > > > I have actually tested it also in BE mode now. Is there any remaining reason not to apply this patch? Thanks Rojhalat Ibrahim From stuartl@longlandclan.hopto.org Thu Feb 10 13:36:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 13:36:45 +0000 (GMT) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:43051 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 13:36:28 +0000 Received: (qmail 14848 invoked by uid 210); 10 Feb 2005 23:36:17 +1000 Received: from 10.0.0.251 by www (envelope-from , uid 201) with qmail-scanner-1.24st (spamassassin: 2.64. perlscan: 1.24st. Clear:RC:1(10.0.0.251):. Processed in 0.115116 secs); 10 Feb 2005 13:36:17 -0000 Received: from unknown (HELO ?10.0.0.251?) (10.0.0.251) by 192.168.5.1 with SMTP; 10 Feb 2005 23:36:17 +1000 Message-ID: <420B6359.7060502@longlandclan.hopto.org> Date: Thu, 10 Feb 2005 23:36:25 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: linux-mips@linux-mips.org Subject: Re: Linux from Scratch References: <420AE7B9.6070202@jg555.com> In-Reply-To: <420AE7B9.6070202@jg555.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="------------enigEEA18C67FC9D311ECCC5B6F6" 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: 7222 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: 3576 Lines: 80 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEEA18C67FC9D311ECCC5B6F6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim Gifford wrote: > I have updated my RaQ2 build for Linux from Scratch to most of the > latest packages for the RaQ2. A question was raised by some other > memebers of the Linux from Scratch group, that frankly I didn't have the > answers for. I appreciate your feedback on these questions. > > 1 - Will the build method I have currently work with any MIPS processor > based machine, with the exception of the bootloader? The bulk of it would be largely the same -- however there would be a difference in that endianness, ABIs and ISAs have to be considered. e.g. Cobalt Servers are Little Endian running RM523[01] CPUs (MIPS IV ISA). All (MIPS-based) SGI machines are Big Endian, mainly with either MIPS III or MIPS IV class CPUs. Therefore you use mips-unknown-linux-gnu as the HOST on SGI boxes, and mipsel-unknown-linux-gnu on Cobalts. (Some even use mips64-unknown-linux-gnu) > 2 - Is there a bootloader for MIPS that will work on every machine, or > is different for every MIPS based machine's firmware? If so any examples > out there how to implement? Okay, a lot of MIPS machines implement the ARCs firmware, but still there's a big variety of machines there -- so making one bootloader support them all would be an outright nightmare. Having said that, there are several bootloaders that do get used across multiple machines. Some that come to mind: - CoLo (the Cobalt Loader) for Cobalt servers - ARCBoot for SGI machines - U-Boot - YAMON and there are likely many more. They've all got their own differences -- just to give you an idea, have a look at my copy of the Gentoo/MIPS handbook[2] -- specifically the bootloader section[3]. This version covers setting up both Cobalt servers and SGI machines with Gentoo Linux. As you can see, there's a big difference between the machines. Anyway, I hope that's answered some of your questions. :-) -- +-------------------------------------------------------------+ | 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. Note that the IP12 and it's R4k cousin, the IP20 are currently unsupported in Linux at this time -- although people are working on that :-) 2. Got the clipboard applet ready? This is a long one: 3. Configuring the Bootloader: ... and yes, eventually this will be put on the main Gentoo site... pending bug #81072: --------------enigEEA18C67FC9D311ECCC5B6F6 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 iD8DBQFCC2NduarJ1mMmSrkRAj8JAJ0cqh0gFfWn6T2xr4Gpi2ZnHCvoQgCgjhCL hd85CHCQSY5LyIQfz+kXjj0= =TCKh -----END PGP SIGNATURE----- --------------enigEEA18C67FC9D311ECCC5B6F6-- From ralf@linux-mips.org Thu Feb 10 13:40:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 13:41:00 +0000 (GMT) Received: from p3EE07839.dip.t-dialin.net ([IPv6:::ffff:62.224.120.57]:2345 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 13:40:44 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j1ADeh9P030919; Thu, 10 Feb 2005 14:40:43 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j1ADehmA030918; Thu, 10 Feb 2005 14:40:43 +0100 Date: Thu, 10 Feb 2005 14:40:43 +0100 From: Ralf Baechle To: Rojhalat Ibrahim Cc: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory Message-ID: <20050210134043.GA30792@linux-mips.org> References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> <20050209000640.GA10651@linux-mips.org> <4209C492.4050201@schenk.isar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4209C492.4050201@schenk.isar.de> 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: 7223 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: 1370 Lines: 49 On Wed, Feb 09, 2005 at 09:06:42AM +0100, Rojhalat Ibrahim wrote: > Ok, thanks. If I can try anything that might help track down > the problem, please let me know. Try this patch which is meant to be used in combination with the previous patch. It moves a test which determines if we actually need to perform a cacheflush to the right place. That's a bug which is harmless on UP but a severe bug on SMP. Thanks, Ralf c-r4k.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) Index: linux-sgi-ip27-ua/arch/mips/mm/c-r4k.c =================================================================== --- linux-sgi-ip27-ua.orig/arch/mips/mm/c-r4k.c 2005-02-10 14:25:54.935572026 +0100 +++ linux-sgi-ip27-ua/arch/mips/mm/c-r4k.c 2005-02-10 14:28:02.329527242 +0100 @@ -376,6 +376,13 @@ pmd_t *pmdp; pte_t *ptep; + /* + * If ownes no valid ASID yet, cannot possibly have gotten + * this page into the cache. + */ + if (cpu_context(smp_processor_id(), vma->vm_mm) == 0) + return; + page &= PAGE_MASK; pgdp = pgd_offset(mm, page); pudp = pud_offset(pgdp, page); @@ -433,13 +440,6 @@ { struct flush_cache_page_args args; - /* - * If ownes no valid ASID yet, cannot possibly have gotten - * this page into the cache. - */ - if (cpu_context(smp_processor_id(), vma->vm_mm) == 0) - return; - args.vma = vma; args.page = page; From ibrahim@schenk.isar.de Thu Feb 10 14:54:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 14:54:58 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:55337 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 14:54:38 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1AEsaH20913; Thu, 10 Feb 2005 15:54:36 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1AEsac32205; Thu, 10 Feb 2005 15:54:36 +0100 Message-ID: <420B75AC.4080209@schenk.isar.de> Date: Thu, 10 Feb 2005 15:54:36 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> <20050209000640.GA10651@linux-mips.org> <4209C492.4050201@schenk.isar.de> <20050210134043.GA30792@linux-mips.org> In-Reply-To: <20050210134043.GA30792@linux-mips.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7224 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 745 Lines: 27 Ralf Baechle wrote: > On Wed, Feb 09, 2005 at 09:06:42AM +0100, Rojhalat Ibrahim wrote: > > >>Ok, thanks. If I can try anything that might help track down >>the problem, please let me know. > > > Try this patch which is meant to be used in combination with the previous > patch. It moves a test which determines if we actually need to perform a > cacheflush to the right place. That's a bug which is harmless on UP but > a severe bug on SMP. > I did a CVS update, which apparently includes this patch, and I get this: LD .tmp_vmlinux1 arch/mips/mm/built-in.o(.init.text+0x98): In function `fixrange_init': : undefined reference to `__pud_offset' make: *** [.tmp_vmlinux1] Error 1 What's __pud_offset? Thanks Rojhalat Ibrahim From ibrahim@schenk.isar.de Thu Feb 10 15:10:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Feb 2005 15:11:00 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:59177 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 10 Feb 2005 15:10:44 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1AFAVH21047; Thu, 10 Feb 2005 16:10:31 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1AFAVc32286; Thu, 10 Feb 2005 16:10:31 +0100 Message-ID: <420B7967.4020105@schenk.isar.de> Date: Thu, 10 Feb 2005 16:10:31 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: More than 512MB of memory References: <41ED20E3.60309@schenk.isar.de> <20050204004028.GC22311@linux-mips.org> <42072264.6000001@schenk.isar.de> <20050208001742.GA15336@linux-mips.org> <42088CFA.6090605@schenk.isar.de> <20050209000640.GA10651@linux-mips.org> <4209C492.4050201@schenk.isar.de> <20050210134043.GA30792@linux-mips.org> In-Reply-To: <20050210134043.GA30792@linux-mips.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7225 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 704 Lines: 23 Ralf Baechle wrote: > On Wed, Feb 09, 2005 at 09:06:42AM +0100, Rojhalat Ibrahim wrote: > > >>Ok, thanks. If I can try anything that might help track down >>the problem, please let me know. > > > Try this patch which is meant to be used in combination with the previous > patch. It moves a test which determines if we actually need to perform a > cacheflush to the right place. That's a bug which is harmless on UP but > a severe bug on SMP. > Also tried it on this morning's source (without the most recent patches). Doesn't make a difference. Still works with 512 MB and crashes with 1 GB. The problem is not SMP related anyway. It appears the same with an UP kernel. Thanks Rojhalat Ibrahim From ftemporelli@astek.fr Fri Feb 11 17:42:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 17:42:54 +0000 (GMT) Received: from mailfe10.tele2.se ([IPv6:::ffff:212.247.155.33]:50912 "EHLO swip.net") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 17:42:32 +0000 X-T2-Posting-ID: g63wq726D5fsXb2UbU6LU0KOXzHnTHjCzHZ35sC2MDs= Received: from [213.103.108.136] (HELO [192.168.0.32]) by mailfe10.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 87498397 for linux-mips@linux-mips.org; Fri, 11 Feb 2005 18:42:23 +0100 Message-ID: <420CEE7F.3080201@astek.fr> Date: Fri, 11 Feb 2005 18:42:23 +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: linux-mips@linux-mips.org Subject: IP32 - issues with last CVS snapshoot 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: 7228 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 Content-Length: 12732 Lines: 307 Hello, I've been able to compile and launch 2.6.11-rc3 from last CVS snapshoot. First, there's something wrong with "make ip32_defconfig" which generate config file with "Kernel code model = 64-bit kernel" (MIPS64=y) but doesn't preselect "Use 64-bit ELF format for building" (BUILD_ELF64=n) doing so, "make" quickly generates an error: --- CC init/main.o Assembler messages: Error: -mgp64 used with a 32-bit ABI --- not too difficult to correct (I'm compiling the kernel on the O2, so I also need to "make menuconf" for removing cross compilation...) Then, may be something to explain: arcboot (3.8.5) can't load ELF64 vmlinuz (I've a segment violation) but is able to load ELF32 (vmlinuz.32) image... Can you confirm that ELF64 are still running with arcboot 3.8.5 ? At last, there are two (non critical) issues when using the kernel: - kernel is reporting only 186MBytes of RAM (384 MBytes avail.). Seems that last Ilya's patch ("full-memV3") is already integrated in this CVS snap... - segmentation fault when using swap At the end of this mail, the boot full dump (arcboot + kernel) Hope this will help. Best regards. Frederic TEMPORELLI PS: now my O2 is booted on serial port... nice for dump ========================================= arcsboot: ARCS Linux ext2fs loader 0.3.8.5 stack starts at: 0xa13faff8 Free Memory(3) segment found at (0x80002000,0x80d50000). Adding 8192 bytes at 0x80002000 to the list of available memory Free Memory(3) segment found at (0x81400000,0x81404000). Free Memory(3) segment found at (0x81412000,0x8c000000). Adding 180281344 bytes at 0x81412000 to the list of available memory mylinux32 is not an envVar Command line: 0: scsi(0)disk(1)rdisk(0)partition(8)/ext2debu 1: mylinux32 2: ConsoleIn=serial(0) 3: ConsoleOut=serial(0) 4: SystemPartition=scsi(0)disk(1)rdisk(0)partition(8) 5: OSLoader=ext2debu 6: OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0) 7: OSLoadFilename=linux64 OSLoadPartition: scsi(0)disk(1)rdisk(0)partition(0) OSLoadFilename: mylinux32 Loading mylinux32 from scsi(0)disk(1)rdisk(0)partition(0) Allocated 0x20 bytes for segments Loading 32-bit executable Loading program segment 1 at 0x80004000, offset=0x4000, size = 0x6d1086 6e4000 (cache: 96.2%) Zeroing memory at 0x806d5086, size = 0x2df9a Command line after config file: 0: /boot/myvmlinux32 1: root=/dev/sda1 Kernel entry: 0x0 8065f000 --- Debug: press to boot kernel --- Starting ELF32 kernel Linux version 2.6.11-rc3 (root@o2) (gcc version 3.4.4 20041218 (prerelease) (Deb ian 3.4.3-6)) #7 Fri Feb 11 16:03:44 UTC 2005 ARCH: SGI-IP32 PROMLIB: ARC firmware Version 1 Revision 10 CRIME id a rev 1 at 0x0000000014000000 CRIME MC: bank 0 base 0x0000000000000000 size 33554432MB CRIME MC: bank 1 base 0x0000000002000000 size 33554432MB CRIME MC: bank 2 base 0x0000000004000000 size 33554432MB CRIME MC: bank 3 base 0x0000000006000000 size 33554432MB CRIME MC: bank 4 base 0x0000000008000000 size 33554432MB CRIME MC: bank 5 base 0x000000000a000000 size 33554432MB CPU revision is: 00002321 FPU revision is: 00002310 Determined physical RAM map: memory: 000000000c000000 @ 0000000000000000 (usable) Built 1 zonelists Kernel command line: root=/dev/sda1 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB, 2-way, linesize 32 bytes. R5000 SCACHE size 1024kB, linesize 32 bytes. Synthesized TLB refill handler (30 instructions). Synthesized TLB load handler fastpath (44 instructions). Synthesized TLB store handler fastpath (44 instructions). Synthesized TLB modify handler fastpath (43 instructions). PID hash table entries: 1024 (order: 10, 32768 bytes) Calibrating system timer... 200 MHz CPU detected Using 100.247 MHz high precision timer. Console: colour dummy device 80x25 CRIME memory error at 0x0d3fffe0 ST 0x0c00a828 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 186048k/196608k available (2627k kernel code, 10304k reserved, 3877k dat a, 476k init, 0k highmem) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) Checking for 'wait' instruction... available. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. NET: Registered protocol family 16 Can't analyze prologue code at ffffffff8028fff0 MACE PCI rev 1 SCSI subsystem initialized MACEPCI: Master abort at 0x00004000 (C) Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing disabled ttyS0 at MMIO 0x0 (irq = 53) is a 16550A ttyS1 at MMIO 0x0 (irq = 59) is a 16550A io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered loop: loaded (max 8 devices) pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com eth0: SGI MACE Ethernet rev. 1 PCI: Enabling device 0000:00:01.0 (0046 -> 0047) ahc_pci:0:1:0: Using left over BIOS settings PCI: Enabling device 0000:00:02.0 (0046 -> 0047) ahc_pci:0:2:0: Using left over BIOS settings scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7880: Wide Channel A, SCSI Id=0, 16/253 SCBs Vendor: SGI Model: IBM DCAS-32160W Rev: S68A Type: Direct-Access ANSI SCSI revision: 02 scsi0:A:1:0: Tagged Queuing enabled. Depth 8 Vendor: SGI Model: IBM DORS-32160W Rev: WA6A Type: Direct-Access ANSI SCSI revision: 02 scsi0:A:2:0: Tagged Queuing enabled. Depth 8 Vendor: TOSHIBA Model: CD-ROM XM-5701TA Rev: 0167 Type: CD-ROM ANSI SCSI revision: 02 scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7880: Wide Channel A, SCSI Id=0, 16/253 SCBs st: Version 20041025, fixed bufsize 32768, s/g segs 256 osst :I: Tape driver with OnStream support version 0.99.3 osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ SCSI device sda: 4197405 512-byte hdwr sectors (2149 MB) SCSI device sda: drive cache: write through SCSI device sda: 4197405 512-byte hdwr sectors (2149 MB) SCSI device sda: drive cache: write through sda: sda1 sda9 sda11 Attached scsi disk sda at scsi0, channel 0, id 1, lun 0 SCSI device sdb: 4197405 512-byte hdwr sectors (2149 MB) SCSI device sdb: drive cache: write through SCSI device sdb: 4197405 512-byte hdwr sectors (2149 MB) SCSI device sdb: drive cache: write through sdb: sdb1 sdb2 sdb9 sdb11 Attached scsi disk sdb at scsi0, channel 0, id 2, lun 0 sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.20 Attached scsi generic sg0 at scsi0, channel 0, id 1, lun 0, type 0 Attached scsi generic sg1 at scsi0, channel 0, id 2, lun 0, type 0 Attached scsi generic sg2 at scsi0, channel 0, id 4, lun 0, type 5 aoe: aoe_init: AoE v2.6-5 initialised. mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 476k freed INIT: version 2.84 booting Loading /etc/console/boottime.kmap.gz Activating swap. CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000 , epc == ffffffff80080d20, ra == ffffffff80080c2c Oops in arch/mips/mm/fault.c::do_page_fault, line 166[#1]: Cpu 0 $ 0 : 0000000000000000 ffffffff806fe000 0000000000000000 0000000040000000 $ 4 : 0000000000000000 0000000000000040 0000000000000001 0000000000000000 $ 8 : 0000000000008000 0000000000000000 000000000000acba ffffffff802e2800 $12 : 0000000000000028 ffffffff80122898 0000000000000000 ffffffff802d4000 $16 : c000000000036000 0000000000037000 0000000000036000 0000000000036000 $20 : 0000000000000000 ffffffffffffffbf 0000000000036000 0000000000036000 $24 : 0000000000000000 ffffffff80021280 $28 : 980000000ba1c000 980000000ba1fcd0 0000000000000040 ffffffff80080c2c Hi : 0000000000023184 Lo : 000000000000bb2c epc : ffffffff80080d20 $L27+0x0/0x4 Not tainted ra : ffffffff80080c2c $LCFI10+0x4c/0x74 Status: 9001fce3 KX SX UX KERNEL EXL IE Cause : 00000008 BadVA : 0000000000000000 PrId : 00002321 Process swapon (pid: 26, threadinfo=980000000ba1c000, task=980000000bfcc698) Stack : 980000000bdebf58 c000000000036000 c000000000036000 ffffffff80702000 0000000000000400 ffffffff80702000 0000000000036000 c000000000035fff 980000000bdebf58 ffffffff806e37f8 0000000000000001 0000000000000035 00000000000000d2 0000000000000040 ffffffff802e2e60 00000000000007df 000000000001a7ea ffffffff80081754 c000000000000000 980000000be32848 ffffffff80081838 0000000000000040 980000000be32848 980000000be32848 980000000bdebf58 ffffffff80081be4 980000000be328d0 0000000000000000 0000000000034fd4 ffffffff806e3848 980000000bae2000 ffffffffffffffea 980000000be35000 980000000b970dd8 980000000132d690 980000000128e170 ffffffff800872c0 ffffffff800868dc 980000000132d5e0 0000000000000000 ... Call Trace: [] $L225+0x8/0x2c [] $L239+0x8/0x18 [] $L324+0x8/0x14 [] $L1135+0x50/0x88 [] $LBE478+0x2c/0x30 [] $L37+0x8/0x18 [] handle_sys+0x11c/0x13c [] $L14+0x8b/0xb8 Code: 0064b00b 00e2a02d 00000000 3c040000 3c018070 64840000 6421 2000 0004203c /etc/init.d/rcS: line 99: 26 Segmentation fault swapon -a 2>/dev/null Checking root file system... fsck 1.27 (8-Mar-2002) /dev/sda1: clean, 21432/261120 files, 178974/521846 blocks ioctl32(hwclock:37): Unknown cmd fd(3) cmd(00004b50){00} arg(7fff7d10) on /dev/t ty1 Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of ouioctl32(hwclock:40): Unknown cmd fd(3) cmd(00004b50){00} arg(7fff7d00) on /dev/tty1 r search for an access method. System tioctl32(hwclock:41): Unknown cmd fd(3) cmd(00004b50){00} arg(7fff7d10) o n /dev/tty1 ime was Fri Feb 11 16:35:09 UTC 2005. Setting the System Clock using the Hardware Clock as reference... Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. System Clock set. System local time is now Fri Feb 11 16:35:09 UTC 2005. Cleaning up ifupdown...done. Checking all file systems... fsck 1.27 (8-Mar-2002) Setting kernel variables ... ... done. Mounting local filesystems... none on /dev/pts type devpts (rw,mode=0620) Running 0dns-down to make sure resolv.conf is ok...done. Initializing: /etc/network/ifstate. Aborting iptables load: unknown ruleset, "active". Setting up IP spoofing protection: rp_filter. Configuring network interfaces...done. Starting portmap daemon: portmap. Loading the saved-state of the serial devices... /dev/ttyS0 at 0x0000 (irq = 53) is a 16550A /dev/ttyS1 at 0x0000 (irq = 59) is a 16550A Setting the System Clock ioctl32(hwclock:117): Unknown cmd fd(3) cmd(00004b50){0 0} arg(7fff7d10) on /dev/tty1 using the Hardware Clock as reference... Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. System Clock set. Local time: Fri Feb 11 16:35:14 UTC 2005 Running ntpdate to synchronize clockError : Name or service not known . Cleaning: /tmp /var/lock /var/run. Initializing random number generator... done. Recovering nvi editor sessions... done. Setting up X server socket directory /tmp/.X11-unix...done. Setting up ICE socket directory /tmp/.ICE-unix...done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Setting up IP spoofing protection: rp_filter. Configuring network interfaces...ifup: interface lo already configured ifup: interface eth0 already configured done. Running ntpdate to synchronize clockError : Name or service not known . Starting portmap daemon: portmap. Starting process accounting: done. Starting internet superserver: inetd. Starting OpenBSD Secure Shell server: sshd. Starting NTP server: ntpd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. Debian GNU/Linux 3.1 o2 ttyS0 ========================================= From geoman@gentoo.org Fri Feb 11 18:14:16 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 18:14:31 +0000 (GMT) Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:49130 "EHLO lennier.cc.vt.edu") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 18:14:16 +0000 Received: from dagger.cc.vt.edu (IDENT:mirapoint@evil-dagger.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j1BIE8ik020923; Fri, 11 Feb 2005 13:14:08 -0500 Received: from [127.0.0.1] (68-232-97-125.chvlva.adelphia.net [68.232.97.125]) by dagger.cc.vt.edu (MOS 3.5.7-GR) with ESMTP id CQB52181 (AUTH spbecker); Fri, 11 Feb 2005 13:14:07 -0500 (EST) Message-ID: <420CF611.5030705@gentoo.org> Date: Fri, 11 Feb 2005 13:14:41 -0500 From: "Stephen P. Becker" User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frederic TEMPORELLI - astek CC: linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot References: <420CEE7F.3080201@astek.fr> In-Reply-To: <420CEE7F.3080201@astek.fr> 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: 7229 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 935 Lines: 21 Frederic TEMPORELLI - astek wrote: > Hello, > > I've been able to compile and launch 2.6.11-rc3 from last CVS snapshoot. > > First, there's something wrong with "make ip32_defconfig" which generate > config file with "Kernel code model = 64-bit kernel" (MIPS64=y) but > doesn't preselect "Use 64-bit ELF format for building" (BUILD_ELF64=n) > doing so, "make" quickly generates an error: O2 doesn't use 64-bit ELF format. You have to use o64. See the arch/mips/Makefile portion of http://dev.gentoo.org/~geoman/cvs.diff for the proper changes. I'm willing to bet a lot of your problems will go away if you stop using ELF64. Such a kernel will boot, but it never quite works right. Not only that, but 64-bit kernels have had some major problems in 2.6.11 so far that I'm not sure Ralf has completely fixed just yet. Last I knew swap still didn't work, so I bet that is where your swap problem is coming from. Steve From macro@linux-mips.org Fri Feb 11 18:41:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 18:42:00 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:12808 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 18:41:44 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 5627CE1C69; Fri, 11 Feb 2005 19:41:37 +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 10390-10; Fri, 11 Feb 2005 19:41:37 +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 01CC4E1C67; Fri, 11 Feb 2005 19:41:37 +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 j1BIffVI024628; Fri, 11 Feb 2005 19:41:41 +0100 Date: Fri, 11 Feb 2005 18:41:50 +0000 (GMT) From: "Maciej W. Rozycki" To: "Stephen P. Becker" Cc: Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot In-Reply-To: <420CF611.5030705@gentoo.org> Message-ID: References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.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: 7230 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: 1619 Lines: 32 On Fri, 11 Feb 2005, Stephen P. Becker wrote: > > First, there's something wrong with "make ip32_defconfig" which generate > > config file with "Kernel code model = 64-bit kernel" (MIPS64=y) but > > doesn't preselect "Use 64-bit ELF format for building" (BUILD_ELF64=n) > > doing so, "make" quickly generates an error: > > O2 doesn't use 64-bit ELF format. You have to use o64. See the O64 isn't a supported ABI for Linux. It's a crazy ad-hoc hack that shouldn't be used at all. Code to handle it somehow may still exist in binutils, but it's abandoned -- nobody bothers checking if it still works. With the upcoming explicit reloc support for non-PIC code in GCC 4.0 it won't work at all anymore. > arch/mips/Makefile portion of http://dev.gentoo.org/~geoman/cvs.diff for the > proper changes. I'm willing to bet a lot of your problems will go away if you > stop using ELF64. Such a kernel will boot, but it never quite works right. If you have a problem with n64 binaries, then either you have broken tools or there is a bug in the platform-dependent code somewhere -- probably some inline asm forgetting about the %higher and %highest relocations. Check your tools (I'd recommend GCC 3.4.3 and binutils 2.15) and if they're fine, then file a bug report. N64 binaries work for several platforms (I've tested three myself; I'm sure others did that for others as well). Regardless of the format used for building, the final executable is converted to ELF32 or ELF64 if necessary to suit the bootloader used, as controlled by the CONFIG_BOOT_ELF32 and CONFIG_BOOT_ELF64 options. Maciej From ilya@total-knowledge.com Fri Feb 11 18:59:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 18:59:15 +0000 (GMT) Received: from mail1.sonicwall.com ([IPv6:::ffff:67.115.118.17]:48338 "EHLO relay1.sonicwall.com") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 18:59:00 +0000 Received: from us0exb02.us.sonicwall.com ([10.50.128.202]) by relay1.sonicwall.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 10:58:55 -0800 Received: from [10.0.15.99] ([10.0.15.99]) by us0exb02.us.sonicwall.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 10:58:54 -0800 Message-ID: <420D006E.3000107@total-knowledge.com> Date: Fri, 11 Feb 2005 10:58:54 -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: "Maciej W. Rozycki" CC: "Stephen P. Becker" , Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2005 18:58:54.0973 (UTC) FILETIME=[BBE3A2D0:01C5106B] 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: 7231 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 Content-Length: 2312 Lines: 70 O64 may not be supported ABI, but it provides us with a feature that is really usefull: specifically, it generates 32 bit symbol addresses instead of 64 bit ones. This cuts down on code size considerably. If this feature was implemented in toolchain as separate switch, O64 hack could go away. With that said, you are of course right - IP32 code and some drivers are broken, because they do rely on this feature in many places. This also means - for a user it isn't recommended to use ElF64 kernel ;-) Maciej W. Rozycki wrote: >On Fri, 11 Feb 2005, Stephen P. Becker wrote: > > > >>>First, there's something wrong with "make ip32_defconfig" which generate >>>config file with "Kernel code model = 64-bit kernel" (MIPS64=y) but >>>doesn't preselect "Use 64-bit ELF format for building" (BUILD_ELF64=n) >>>doing so, "make" quickly generates an error: >>> >>> >>O2 doesn't use 64-bit ELF format. You have to use o64. See the >> >> > > O64 isn't a supported ABI for Linux. It's a crazy ad-hoc hack that >shouldn't be used at all. Code to handle it somehow may still exist in >binutils, but it's abandoned -- nobody bothers checking if it still works. >With the upcoming explicit reloc support for non-PIC code in GCC 4.0 it >won't work at all anymore. > > > >>arch/mips/Makefile portion of http://dev.gentoo.org/~geoman/cvs.diff for the >>proper changes. I'm willing to bet a lot of your problems will go away if you >>stop using ELF64. Such a kernel will boot, but it never quite works right. >> >> > > If you have a problem with n64 binaries, then either you have broken >tools or there is a bug in the platform-dependent code somewhere -- >probably some inline asm forgetting about the %higher and %highest >relocations. Check your tools (I'd recommend GCC 3.4.3 and binutils 2.15) >and if they're fine, then file a bug report. N64 binaries work for >several platforms (I've tested three myself; I'm sure others did that >for others as well). > > Regardless of the format used for building, the final executable is >converted to ELF32 or ELF64 if necessary to suit the bootloader used, as >controlled by the CONFIG_BOOT_ELF32 and CONFIG_BOOT_ELF64 options. > > Maciej > > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From macro@linux-mips.org Fri Feb 11 19:27:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 19:27:20 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:31241 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 19:27:04 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 48942E1C77; Fri, 11 Feb 2005 20:26:58 +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 12816-07; Fri, 11 Feb 2005 20:26:58 +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 EED75E1C67; Fri, 11 Feb 2005 20:26:57 +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 j1BJR2Nm026856; Fri, 11 Feb 2005 20:27:02 +0100 Date: Fri, 11 Feb 2005 19:27:13 +0000 (GMT) From: "Maciej W. Rozycki" To: "Ilya A. Volynets-Evenbakh" Cc: "Stephen P. Becker" , Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot In-Reply-To: <420D006E.3000107@total-knowledge.com> Message-ID: References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> <420D006E.3000107@total-knowledge.com> 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: 7232 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: 1032 Lines: 25 On Fri, 11 Feb 2005, Ilya A. Volynets-Evenbakh wrote: > O64 may not be supported ABI, but it provides us with a feature that is really > usefull: > specifically, it generates 32 bit symbol addresses instead of 64 bit ones. > This cuts > down on code size considerably. If this feature was implemented in toolchain > as separate > switch, O64 hack could go away. Well, the topic has been beaten to death here, so you don't really need to illuminate me -- it's only due to this popular request I've implemented the ability to do 32-bit builds for 64-bit kernel. I just wonder why people insisting on such a setup don't actually contribute some code to do that cleanly and keep switching between hacks as they stop working one by one... > With that said, you are of course right - IP32 code and some drivers are > broken, because > they do rely on this feature in many places. Having a compiled tree in place these bugs are trivial to track down with "find", "objdump", "grep" and some usual shell script magic. Maciej From ilya@total-knowledge.com Fri Feb 11 19:34:28 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 19:34:44 +0000 (GMT) Received: from mail.sonicwall.com ([IPv6:::ffff:67.115.118.12]:31816 "EHLO relay.sonicwall.com") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 19:34:28 +0000 Received: from us0exb02.us.sonicwall.com ([10.50.128.202]) by relay.sonicwall.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 11:34:26 -0800 Received: from [10.0.15.99] ([10.0.15.99]) by us0exb02.us.sonicwall.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 11:34:26 -0800 Message-ID: <420D08C1.8050105@total-knowledge.com> Date: Fri, 11 Feb 2005 11:34:25 -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: "Maciej W. Rozycki" CC: "Stephen P. Becker" , Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> <420D006E.3000107@total-knowledge.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2005 19:34:26.0061 (UTC) FILETIME=[B21DDBD0:01C51070] 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: 7233 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 Content-Length: 972 Lines: 36 Maciej W. Rozycki wrote: >On Fri, 11 Feb 2005, Ilya A. Volynets-Evenbakh wrote: > > > >>O64 may not be supported ABI, but it provides us with a feature that is really >>usefull: >>specifically, it generates 32 bit symbol addresses instead of 64 bit ones. >>This cuts >>down on code size considerably. If this feature was implemented in toolchain >>as separate >>switch, O64 hack could go away. >> >> > > Well, the topic has been beaten to death here, so you don't really need >to illuminate me -- it's only due to this popular request I've implemented >the ability to do 32-bit builds for 64-bit kernel. > I know > I just wonder why >people insisting on such a setup don't actually contribute some code to do >that cleanly and keep switching between hacks as they stop working one by >one... > > Because they hope that if they annoy you enough, you'll do it yourself ;-) -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From geoman@gentoo.org Fri Feb 11 19:38:41 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 19:38:57 +0000 (GMT) Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:41940 "EHLO lennier.cc.vt.edu") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 19:38:41 +0000 Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j1BJcTBN021208; Fri, 11 Feb 2005 14:38:29 -0500 Received: from [127.0.0.1] (68-232-97-125.chvlva.adelphia.net [68.232.97.125]) by vivi.cc.vt.edu (MOS 3.5.7-GR) with ESMTP id CPG70006 (AUTH spbecker); Fri, 11 Feb 2005 14:38:26 -0500 (EST) Message-ID: <420D09D3.2090405@gentoo.org> Date: Fri, 11 Feb 2005 14:38:59 -0500 From: "Stephen P. Becker" User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Ilya A. Volynets-Evenbakh" , Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> <420D006E.3000107@total-knowledge.com> In-Reply-To: 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: 7234 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1240 Lines: 31 Maciej W. Rozycki wrote: > On Fri, 11 Feb 2005, Ilya A. Volynets-Evenbakh wrote: > > >>O64 may not be supported ABI, but it provides us with a feature that is really >>usefull: >>specifically, it generates 32 bit symbol addresses instead of 64 bit ones. >>This cuts >>down on code size considerably. If this feature was implemented in toolchain >>as separate >>switch, O64 hack could go away. > > > Well, the topic has been beaten to death here, so you don't really need > to illuminate me -- it's only due to this popular request I've implemented > the ability to do 32-bit builds for 64-bit kernel. I just wonder why > people insisting on such a setup don't actually contribute some code to do > that cleanly and keep switching between hacks as they stop working one by > one... > Well, it wasn't my intention to beat anything to death mentioning the o64 hack. I'm just pointing out that using n64 for an ip32 kernel results in a broken kernel at this point in time...plain and simple. Therefore we have to use this hack. Another point though is that n64 kernels are very large, and apparently ip32 has issues booting kernels larger than about 8mb. So either way, n64 isn't a good idea for o32 at this time. Steve From macro@linux-mips.org Fri Feb 11 19:50:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Feb 2005 19:50:21 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:18950 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 11 Feb 2005 19:50:06 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 9DB83E1C7A; Fri, 11 Feb 2005 20:49:59 +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 11701-01; Fri, 11 Feb 2005 20:49:59 +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 4B573E1C79; Fri, 11 Feb 2005 20:49:59 +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 j1BJo4TK027887; Fri, 11 Feb 2005 20:50:04 +0100 Date: Fri, 11 Feb 2005 19:50:14 +0000 (GMT) From: "Maciej W. Rozycki" To: "Ilya A. Volynets-Evenbakh" Cc: "Stephen P. Becker" , Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot In-Reply-To: <420D08C1.8050105@total-knowledge.com> Message-ID: References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> <420D006E.3000107@total-knowledge.com> <420D08C1.8050105@total-knowledge.com> 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: 7235 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: 468 Lines: 13 On Fri, 11 Feb 2005, Ilya A. Volynets-Evenbakh wrote: > > I just wonder why people insisting on such a setup don't actually > > contribute some code to do that cleanly and keep switching between hacks > > as they stop working one by one... > > > > > Because they hope that if they annoy you enough, you'll do it yourself ;-) Well, since the kernel can be built as ELF64 with no trouble, you'd rather not bet on it. I couldn't care less, sorry... ;-) Maciej From kumba@gentoo.org Sat Feb 12 00:54:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Feb 2005 00:54:45 +0000 (GMT) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:3529 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Sat, 12 Feb 2005 00:54:29 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (rwcrmhc13) with ESMTP id <2005021200541601500e6t10e>; Sat, 12 Feb 2005 00:54:20 +0000 Message-ID: <420D5374.4000006@gentoo.org> Date: Fri, 11 Feb 2005 19:53:08 -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: IP32 - issues with last CVS snapshoot References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> <420D006E.3000107@total-knowledge.com> In-Reply-To: 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: 7236 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: 1240 Lines: 38 Maciej W. Rozycki wrote: > On Fri, 11 Feb 2005, Ilya A. Volynets-Evenbakh wrote: > > >>O64 may not be supported ABI, but it provides us with a feature that is really >>usefull: >>specifically, it generates 32 bit symbol addresses instead of 64 bit ones. >>This cuts >>down on code size considerably. If this feature was implemented in toolchain >>as separate >>switch, O64 hack could go away. > > > Well, the topic has been beaten to death here, so you don't really need > to illuminate me -- it's only due to this popular request I've implemented > the ability to do 32-bit builds for 64-bit kernel. I just wonder why > people insisting on such a setup don't actually contribute some code to do > that cleanly and keep switching between hacks as they stop working one by > one... > I believe it was mentioned at some point in time by someone that using "n32" inplace of "o64" might have a similar affect of "o64", but I can't recall what the outcome of that actually was (or whether or not it ever worked). As if I could be any more vague. --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 Sat Feb 12 01:54:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Feb 2005 01:54:34 +0000 (GMT) Received: from p3EE2BC3E.dip.t-dialin.net ([IPv6:::ffff:62.226.188.62]:13632 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 12 Feb 2005 01:54:11 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j1C1s62u012433; Sat, 12 Feb 2005 02:54:06 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j1C1s0Jp012432; Sat, 12 Feb 2005 02:54:00 +0100 Date: Sat, 12 Feb 2005 02:54:00 +0100 From: Ralf Baechle To: "Stephen P. Becker" Cc: Frederic TEMPORELLI - astek , linux-mips@linux-mips.org Subject: Re: IP32 - issues with last CVS snapshoot Message-ID: <20050212015400.GA26873@linux-mips.org> References: <420CEE7F.3080201@astek.fr> <420CF611.5030705@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420CF611.5030705@gentoo.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: 7237 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: 1048 Lines: 20 On Fri, Feb 11, 2005 at 01:14:41PM -0500, Stephen P. Becker wrote: > >First, there's something wrong with "make ip32_defconfig" which generate > >config file with "Kernel code model = 64-bit kernel" (MIPS64=y) but > >doesn't preselect "Use 64-bit ELF format for building" (BUILD_ELF64=n) > >doing so, "make" quickly generates an error: > > O2 doesn't use 64-bit ELF format. You have to use o64. See the > arch/mips/Makefile portion of http://dev.gentoo.org/~geoman/cvs.diff for > the proper changes. I'm willing to bet a lot of your problems will go > away if you stop using ELF64. Such a kernel will boot, but it never > quite works right. Not only that, but 64-bit kernels have had some > major problems in 2.6.11 so far that I'm not sure Ralf has completely > fixed just yet. Last I knew swap still didn't work, so I bet that is > where your swap problem is coming from. I fixed that also but it's still not stable. As a test I did rebuild e2fsutils and it did panic after a while. So midnight oil to the rescue ... Ralf From nsekhar@ti.com Sat Feb 12 10:56:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Feb 2005 10:56:54 +0000 (GMT) Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:63886 "EHLO go4.ext.ti.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 12 Feb 2005 10:56:38 +0000 Received: from dlep91.itg.ti.com ([157.170.152.55]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j1CAuWdK008735; Sat, 12 Feb 2005 04:56:32 -0600 (CST) Received: from dbde2k01.ent.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id j1CAuTqd007197; Sat, 12 Feb 2005 04:56:31 -0600 (CST) 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: [PATCH] Using JR instead of J instruction for jumping to IRQ handler. Date: Sat, 12 Feb 2005 16:26:29 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Using JR instead of J instruction for jumping to IRQ handler. Thread-Index: AcUQ8YEwNbMGh39vSYeT7CEO3F7rjg== From: "Nori, Soma Sekhar" To: Cc: 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: 7239 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: 1329 Lines: 36 Hi Ralf, Attached patch attempts to use load address k0, followed by jump register k0 to jump to the MIPS IRQ handler from CAC_BASE + 0x200 instead of just jump . This will enable jumping even if IRQ handler is linked at high kernel logical address. (like 0x94000000+). I have tested this to work fine on my 4kec. (Not sure if the code will hold good for MIPS64 though) Thanks, Sekhar Nori. --- linux.orig/arch/mips/kernel/traps.c 2004-12-25 03:04:32.000000000 +0530 +++ linux/arch/mips/kernel/traps.c 2005-02-12 14:53:32.465876000 +0530 @@ -848,9 +848,12 @@ exception_handlers[n] = handler; if (n == 0 && cpu_has_divec) { - *(volatile u32 *)(CAC_BASE + 0x200) = 0x08000000 | - (0x03ffffff & (handler >> 2)); - flush_icache_range(CAC_BASE + 0x200, CAC_BASE + 0x204); + *(volatile u32 *)(CAC_BASE + 0x200) = 0x3c1a0000 | + (handler >> 16); + *(volatile u32 *)(CAC_BASE + 0x204) = 0x375a0000 | + (handler & 0xFFFF); + *(volatile u32 *)(CAC_BASE + 0x208) = 0x03400008; + flush_icache_range(CAC_BASE + 0x200, CAC_BASE + 0x20C); } return (void *)old_handler; } From rsandifo@redhat.com Sat Feb 12 13:07:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Feb 2005 13:07:22 +0000 (GMT) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:19166 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Sat, 12 Feb 2005 13:07:06 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1CD74gb031268 for ; Sat, 12 Feb 2005 08:07:04 -0500 Received: from firetop.home (vpn50-8.rdu.redhat.com [172.16.50.8]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1CD6xO20655 for ; Sat, 12 Feb 2005 08:06:59 -0500 Received: from rsandifo by firetop.home with local (Exim 4.34) id 1CzwzI-00012g-3r for linux-mips@linux-mips.org; Sat, 12 Feb 2005 13:07:04 +0000 To: linux-mips@linux-mips.org Subject: Possible thinko in driver/net/sb1250-mac.c? From: Richard Sandiford Date: Sat, 12 Feb 2005 13:07:04 +0000 Message-ID: <87wttekjuv.fsf@firetop.home> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 7240 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 1882 Lines: 50 [ As usual, I have a feeling I'm either showing my ignorance or going over well-trodden ground, but here goes.. ] I was looking at driver/net/sb1250-mac.c, and I noticed that it effectively maintains a gap of _two_ empty buffers in the receive ring. As expected, sbdma_fillring() sets things up so that the gap is only a single buffer (assuming enough free memory): for (idx = 0; idx < SBMAC_MAX_RXDESCR-1; idx++) { if (sbdma_add_rcvbuffer(d,NULL) != 0) break; } but the first time sbdma_rx_process() is called, it fails to replace the buffer it reads with a new one. The reason is that sbdma_rx_process() is structured like this: if (packet in sb was received OK) { if (sbdma_add_rcvbuffer(d,NULL) == -ENOBUFS) { ... Drop the packet and add sb back to the ring ... sbdma_add_rcvbuffer(d,sb); } else { ... Hand sb off to netif_rx ... } } else { ... Record the error and add sb back to the ring ... sbdma_add_rcvbuffer(d,sb); } d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr); where sbdma_remptr is only updated _after_ calling sbdma_add_rcvbuffer(). But sbdma_add_rcvbuffer() uses sbdma_remptr to check whether the ring is full: dsc = d->sbdma_addptr; nextdsc = SBDMA_NEXTBUF(d,sbdma_addptr); if (nextdsc == d->sbdma_remptr) { return -ENOSPC; } So when sbdma_add_rcvbuffer() is called for the first time after sbdma_fillring(), the call to sbdma_add_rcvbuffer() will fail with ENOSPC (verified with various printk()s) and no buffer will be added. I guess this doesn't matter much if the first packet is received OK. But if it isn't, and the receive code takes the error path, I think it'll end up leaking a buffer. Richard From macro@linux-mips.org Sun Feb 13 05:54:47 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Feb 2005 05:55:04 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:27147 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Sun, 13 Feb 2005 05:54:47 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id DE926E1CB5; Sun, 13 Feb 2005 06:54:40 +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 11980-09; Sun, 13 Feb 2005 06:54:40 +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 9FA69E1CB0; Sun, 13 Feb 2005 06:54:40 +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 j1D5sb5S001231; Sun, 13 Feb 2005 06:54:42 +0100 Date: Sun, 13 Feb 2005 05:54:37 +0000 (GMT) From: "Maciej W. Rozycki" To: "Nori, Soma Sekhar" Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Using JR instead of J instruction for jumping to IRQ handler. In-Reply-To: Message-ID: References: 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: 7241 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: 911 Lines: 20 On Sat, 12 Feb 2005, Nori, Soma Sekhar wrote: > Attached patch attempts to use load address k0, followed by > jump register k0 to jump to the MIPS IRQ handler from CAC_BASE + 0x200 > instead of just jump . This will enable jumping even if IRQ > handler is linked at high kernel logical address. (like 0x94000000+). > > I have tested this to work fine on my 4kec. (Not sure if the code will > hold good for MIPS64 though) Well, it's where it would actually be especially useful, specifically for 64-bit kernels loaded at XPHYS addresses. Given it's generated code and this way of handling interrupts aims at improving performance (otherwise why bother using a separate vector at all?), it should actually determine whether an absolute jump suffices and emit code appropriately. That said, with the 4KEc you'd probably be better with using the CP0 Ebase register instead. Maciej From macro@linux-mips.org Sun Feb 13 21:33:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Feb 2005 21:34:01 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:11268 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Sun, 13 Feb 2005 21:33:45 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 38A44F5944 for ; Sun, 13 Feb 2005 22:33:33 +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 07752-08 for ; Sun, 13 Feb 2005 22:33:33 +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 6D63AE1CDB for ; Sun, 13 Feb 2005 22:33:31 +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 j1DLXb8f002083 for ; Sun, 13 Feb 2005 22:33:37 +0100 Date: Sun, 13 Feb 2005 21:33:48 +0000 (GMT) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux In-Reply-To: <20050213213130Z8225210-1340+3164@linux-mips.org> Message-ID: References: <20050213213130Z8225210-1340+3164@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: 7243 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 On Sun, 13 Feb 2005 ralf@linux-mips.org wrote: > Modified files: > arch/mips : Kconfig > > Log message: > If you want RM7000 better fix it to build first ... It works for me -- if you want a fix, then tell me what exactly is wrong. Perhaps your compiler is broken. Maciej From drow@nevyn.them.org Mon Feb 14 02:02:25 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 02:02:41 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:35048 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 02:02:25 +0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D0VYv-0006d5-52; Sun, 13 Feb 2005 21:02:09 -0500 Date: Sun, 13 Feb 2005 21:02:09 -0500 From: Daniel Jacobowitz To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: Support /proc/kcore for MIPS Message-ID: <20050214020209.GA25335@nevyn.them.org> References: <20050121005954.GA10260@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050121005954.GA10260@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: 7244 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 Ping. I've now tested this patch in both 32-bit and 64-bit kernels. On Thu, Jan 20, 2005 at 07:59:54PM -0500, Daniel Jacobowitz wrote: > I wanted to do live debugging on an ornery task_struct this morning, so I > hooked up /proc/kcore for MIPS. I'm pretty sure that the CKSEG0 bits are > wrong, but I did need to cover that region - because the SB-1 kernel links > at 0xffffffff80100000 or so, disassembly and printing static variables don't > work unless the debugger can read that region. > > Signed-off-by: Daniel Jacobowitz > > Index: linux/arch/mips/mm/init.c > =================================================================== > --- linux.orig/arch/mips/mm/init.c 2005-01-20 16:26:58.791321462 -0500 > +++ linux/arch/mips/mm/init.c 2005-01-20 16:34:27.231213174 -0500 > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -197,6 +198,11 @@ > return 0; > } > > +static struct kcore_list kcore_mem, kcore_vmalloc; > +#ifdef CONFIG_MIPS64 > +static struct kcore_list kcore_kseg0; > +#endif > + > void __init mem_init(void) > { > unsigned long codesize, reservedpages, datasize, initsize; > @@ -247,6 +253,16 @@ > datasize = (unsigned long) &_edata - (unsigned long) &_etext; > initsize = (unsigned long) &__init_end - (unsigned long) &__init_begin; > > +#ifdef CONFIG_MIPS64 > + if ((unsigned long) &_text > (unsigned long) CKSEG0) > + /* The -4 is a hack so that user tools don't have to handle > + the overflow. */ > + kclist_add(&kcore_kseg0, (void *) CKSEG0, 0x80000000 - 4); > +#endif > + kclist_add(&kcore_mem, __va(0), max_low_pfn << PAGE_SHIFT); > + kclist_add(&kcore_vmalloc, (void *)VMALLOC_START, > + VMALLOC_END-VMALLOC_START); > + > printk(KERN_INFO "Memory: %luk/%luk available (%ldk kernel code, " > "%ldk reserved, %ldk data, %ldk init, %ldk highmem)\n", > (unsigned long) nr_free_pages() << (PAGE_SHIFT-10), > > -- > Daniel Jacobowitz > > -- Daniel Jacobowitz CodeSourcery, LLC From drow@nevyn.them.org Mon Feb 14 02:26:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 02:26:19 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:55760 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 02:26:02 +0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D0Vw1-0006nJ-IN for ; Sun, 13 Feb 2005 21:26:01 -0500 Date: Sun, 13 Feb 2005 21:26:01 -0500 From: Daniel Jacobowitz To: linux-mips@linux-mips.org Subject: Re: Fix o32 core dumps on 64-bit kernel Message-ID: <20050214022601.GB25335@nevyn.them.org> References: <20050121010133.GA10319@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050121010133.GA10319@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: 7245 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 The core dump code in binfmt_elfo32.c has bitrotted. It no longer worked after elfcore.h started using inline functions - not sure when that was. With this, I have both single-threaded and multi-threaded core dumps working. I'm not sure about the FP bits, if a task is currently using hardware FP, but I just copied the existing brokenness from dump_fpu. Better than nothing. This patch also adds "$0" (saved syscall number), $k0, and $k1 back to the coredump. Don't worry, GDB knows that this isn't the real $0 value. Updated for current 2.6 CVS. Signed-off-by: Daniel Jacobowitz Index: linux/arch/mips/kernel/binfmt_elfo32.c =================================================================== --- linux.orig/arch/mips/kernel/binfmt_elfo32.c 2005-02-02 09:16:20.000000000 -0500 +++ linux/arch/mips/kernel/binfmt_elfo32.c 2005-02-13 21:03:23.068817064 -0500 @@ -54,43 +54,9 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_N #include #include -#include #include - -#define elf_prstatus elf_prstatus32 -struct elf_prstatus32 -{ - struct elf_siginfo pr_info; /* Info associated with signal */ - short pr_cursig; /* Current signal */ - unsigned int pr_sigpend; /* Set of pending signals */ - unsigned int pr_sighold; /* Set of held signals */ - pid_t pr_pid; - pid_t pr_ppid; - pid_t pr_pgrp; - pid_t pr_sid; - struct compat_timeval pr_utime; /* User time */ - struct compat_timeval pr_stime; /* System time */ - struct compat_timeval pr_cutime;/* Cumulative user time */ - struct compat_timeval pr_cstime;/* Cumulative system time */ - elf_gregset_t pr_reg; /* GP registers */ - int pr_fpvalid; /* True if math co-processor being used. */ -}; - -#define elf_prpsinfo elf_prpsinfo32 -struct elf_prpsinfo32 -{ - char pr_state; /* numeric process state */ - char pr_sname; /* char for pr_state */ - char pr_zomb; /* zombie */ - char pr_nice; /* nice val */ - unsigned int pr_flag; /* flags */ - __kernel_uid_t pr_uid; - __kernel_gid_t pr_gid; - pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid; - /* Lots missing */ - char pr_fname[16]; /* filename of executable */ - char pr_psargs[ELF_PRARGSZ]; /* initial part of arg list */ -}; +#include +#include #define elf_addr_t u32 #define elf_caddr_t u32 @@ -109,20 +75,19 @@ jiffies_to_compat_timeval(unsigned long value->tv_usec /= NSEC_PER_USEC; } +/* These need to be here, before the incluson of elfcore.h. */ + #undef ELF_CORE_COPY_REGS #define ELF_CORE_COPY_REGS(_dest,_regs) elf32_core_copy_regs(_dest,_regs); -void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs) +static void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs) { int i; for (i = 0; i < EF_R0; i++) grp[i] = 0; - grp[EF_R0] = 0; - for (i = 1; i <= 31; i++) + for (i = 0; i <= 31; i++) grp[EF_R0 + i] = (elf_greg_t) regs->regs[i]; - grp[EF_R26] = 0; - grp[EF_R27] = 0; grp[EF_LO] = (elf_greg_t) regs->lo; grp[EF_HI] = (elf_greg_t) regs->hi; grp[EF_CP0_EPC] = (elf_greg_t) regs->cp0_epc; @@ -134,6 +99,65 @@ void elf32_core_copy_regs(elf_gregset_t #endif } +#undef ELF_CORE_COPY_TASK_REGS +#define ELF_CORE_COPY_TASK_REGS(_task,_dest) elf32_core_copy_task_regs(_task, *(_dest)) + +static int elf32_core_copy_task_regs(struct task_struct *_task, elf_gregset_t _dest) +{ + struct pt_regs *_regs; + _regs = (struct pt_regs *) ((unsigned long) _task->thread_info + + THREAD_SIZE - 32 - sizeof (struct pt_regs)); + elf32_core_copy_regs (_dest, _regs); + return 1; +} + +#undef ELF_CORE_COPY_FPREGS +#define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) elf32_dump_task_fpu(tsk, elf_fpregs) + +static int elf32_dump_task_fpu(struct task_struct *tsk, elf_fpregset_t *fpu) +{ + /* FIXME: Is this right? */ + memcpy(fpu, &tsk->thread.fpu, sizeof(tsk->thread.fpu)); + return 1; +} + +#include + +#define elf_prstatus elf_prstatus32 +struct elf_prstatus32 +{ + struct elf_siginfo pr_info; /* Info associated with signal */ + short pr_cursig; /* Current signal */ + unsigned int pr_sigpend; /* Set of pending signals */ + unsigned int pr_sighold; /* Set of held signals */ + pid_t pr_pid; + pid_t pr_ppid; + pid_t pr_pgrp; + pid_t pr_sid; + struct compat_timeval pr_utime; /* User time */ + struct compat_timeval pr_stime; /* System time */ + struct compat_timeval pr_cutime;/* Cumulative user time */ + struct compat_timeval pr_cstime;/* Cumulative system time */ + elf_gregset_t pr_reg; /* GP registers */ + int pr_fpvalid; /* True if math co-processor being used. */ +}; + +#define elf_prpsinfo elf_prpsinfo32 +struct elf_prpsinfo32 +{ + char pr_state; /* numeric process state */ + char pr_sname; /* char for pr_state */ + char pr_zomb; /* zombie */ + char pr_nice; /* nice val */ + unsigned int pr_flag; /* flags */ + __kernel_uid_t pr_uid; + __kernel_gid_t pr_gid; + pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid; + /* Lots missing */ + char pr_fname[16]; /* filename of executable */ + char pr_psargs[ELF_PRARGSZ]; /* initial part of arg list */ +}; + MODULE_DESCRIPTION("Binary format loader for compatibility with o32 Linux/MIPS binaries"); MODULE_AUTHOR("Ralf Baechle (ralf@linux-mips.org)"); Index: linux/arch/mips/kernel/process.c =================================================================== --- linux.orig/arch/mips/kernel/process.c 2005-02-13 20:55:57.665590299 -0500 +++ linux/arch/mips/kernel/process.c 2005-02-13 21:18:26.230390943 -0500 @@ -163,11 +163,8 @@ void dump_regs(elf_greg_t *gp, struct pt for (i = 0; i < EF_R0; i++) gp[i] = 0; - gp[EF_R0] = 0; - for (i = 1; i <= 31; i++) + for (i = 0; i <= 31; i++) gp[EF_R0 + i] = regs->regs[i]; - gp[EF_R26] = 0; - gp[EF_R27] = 0; gp[EF_LO] = regs->lo; gp[EF_HI] = regs->hi; gp[EF_CP0_EPC] = regs->cp0_epc; -- Daniel Jacobowitz CodeSourcery, LLC From drow@nevyn.them.org Mon Feb 14 02:36:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 02:36:25 +0000 (GMT) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:41157 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 02:36:08 +0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D0W5n-0006pQ-5a; Sun, 13 Feb 2005 21:36:07 -0500 Date: Sun, 13 Feb 2005 21:36:07 -0500 From: Daniel Jacobowitz To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Fix up 32-bit compat for a bunch of syscalls Message-ID: <20050214023607.GC25335@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: 7246 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 A grab bag of fixes from testing glibc, o32 only, under both 32-bit and 64-bit kernels. Changes are: - There is a generic compat_sys_wait4; use it. - waitid needs compat routines for o32 (siginfo and rusage) and n32 (just rusage). - timer_create needs a compat routine for both o32 and n32 (struct sigevent). - rt_sigtimedwait can use the generic compat routine for o32, but not for n32, because n32 uses a 64-bit struct siginfo. I didn't actually test this one yet - I'll be doing n32 testing in a couple of weeks... - For the same reason n32 should not use sys32_rt_sigqueueinfo. - n32 does need compat versions of the other timer_* and clock_* functions however. - o32 signal delivery was not handling SI_TIMER. - waitid takes five arguments now, not four. - PTRACE_GETEVENTMSG needs a compat wrapper since it writes a long to userspace. With these, I get the same o32 glibc test results using a 32-bit or 64-bit kernel on my Sentosa. The only thing left which looks like a kernel bug is time-related; a bunch of the POSIX timers tests complain that timers trigger too soon. Please apply if OK. Signed-off-by: Daniel Jacobowitz Index: linux/arch/mips/kernel/linux32.c =================================================================== --- linux.orig/arch/mips/kernel/linux32.c 2005-02-13 20:55:57.729574958 -0500 +++ linux/arch/mips/kernel/linux32.c 2005-02-13 21:28:08.198089040 -0500 @@ -215,81 +215,36 @@ sys32_readdir(unsigned int fd, void * di return(n); } -struct rusage32 { - struct compat_timeval ru_utime; - struct compat_timeval ru_stime; - int ru_maxrss; - int ru_ixrss; - int ru_idrss; - int ru_isrss; - int ru_minflt; - int ru_majflt; - int ru_nswap; - int ru_inblock; - int ru_oublock; - int ru_msgsnd; - int ru_msgrcv; - int ru_nsignals; - int ru_nvcsw; - int ru_nivcsw; -}; -static int -put_rusage (struct rusage32 *ru, struct rusage *r) -{ - int err; +asmlinkage int compat_sys_wait4(compat_pid_t pid, unsigned int * stat_addr, + int options, struct compat_rusage * ru); - if (verify_area(VERIFY_WRITE, ru, sizeof *ru)) - return -EFAULT; - - err = __put_user (r->ru_utime.tv_sec, &ru->ru_utime.tv_sec); - err |= __put_user (r->ru_utime.tv_usec, &ru->ru_utime.tv_usec); - err |= __put_user (r->ru_stime.tv_sec, &ru->ru_stime.tv_sec); - err |= __put_user (r->ru_stime.tv_usec, &ru->ru_stime.tv_usec); - err |= __put_user (r->ru_maxrss, &ru->ru_maxrss); - err |= __put_user (r->ru_ixrss, &ru->ru_ixrss); - err |= __put_user (r->ru_idrss, &ru->ru_idrss); - err |= __put_user (r->ru_isrss, &ru->ru_isrss); - err |= __put_user (r->ru_minflt, &ru->ru_minflt); - err |= __put_user (r->ru_majflt, &ru->ru_majflt); - err |= __put_user (r->ru_nswap, &ru->ru_nswap); - err |= __put_user (r->ru_inblock, &ru->ru_inblock); - err |= __put_user (r->ru_oublock, &ru->ru_oublock); - err |= __put_user (r->ru_msgsnd, &ru->ru_msgsnd); - err |= __put_user (r->ru_msgrcv, &ru->ru_msgrcv); - err |= __put_user (r->ru_nsignals, &ru->ru_nsignals); - err |= __put_user (r->ru_nvcsw, &ru->ru_nvcsw); - err |= __put_user (r->ru_nivcsw, &ru->ru_nivcsw); - - return err; +asmlinkage int +sys32_waitpid(compat_pid_t pid, unsigned int *stat_addr, int options) +{ + return compat_sys_wait4(pid, stat_addr, options, NULL); } -asmlinkage int -sys32_wait4(compat_pid_t pid, unsigned int * stat_addr, int options, - struct rusage32 * ru) +asmlinkage long +sysn32_waitid(int which, compat_pid_t pid, + siginfo_t __user *uinfo, int options, + struct compat_rusage __user *uru) { - if (!ru) - return sys_wait4(pid, stat_addr, options, NULL); - else { - struct rusage r; - int ret; - unsigned int status; - mm_segment_t old_fs = get_fs(); + struct rusage ru; + long ret; + mm_segment_t old_fs = get_fs(); - set_fs(KERNEL_DS); - ret = sys_wait4(pid, stat_addr ? &status : NULL, options, &r); - set_fs(old_fs); - if (put_rusage (ru, &r)) return -EFAULT; - if (stat_addr && put_user (status, stat_addr)) - return -EFAULT; + set_fs (KERNEL_DS); + ret = sys_waitid(which, pid, uinfo, options, + uru ? (struct rusage __user *) &ru : NULL); + set_fs (old_fs); + + if (ret < 0 || uinfo->si_signo == 0) return ret; - } -} -asmlinkage int -sys32_waitpid(compat_pid_t pid, unsigned int *stat_addr, int options) -{ - return sys32_wait4(pid, stat_addr, options, NULL); + if (uru) + ret = put_compat_rusage(&ru, uru); + return ret; } struct sysinfo32 { @@ -1496,3 +1451,53 @@ _sys32_clone(unsigned long __dummy0, return do_fork(clone_flags, newsp, ®s, 0, parent_tidptr, child_tidptr); } + +struct sigevent32 { + u32 sigev_value; + u32 sigev_signo; + u32 sigev_notify; + u32 payload[(64 / 4) - 3]; +}; + +extern asmlinkage long +sys_timer_create(clockid_t which_clock, + struct sigevent __user *timer_event_spec, + timer_t __user * created_timer_id); + +long +sys32_timer_create(u32 clock, struct sigevent32 __user *se32, timer_t __user *timer_id) +{ + struct sigevent __user *p = NULL; + if (se32) { + struct sigevent se; + p = compat_alloc_user_space(sizeof(struct sigevent)); + memset(&se, 0, sizeof(struct sigevent)); + if (get_user(se.sigev_value.sival_int, &se32->sigev_value) || + __get_user(se.sigev_signo, &se32->sigev_signo) || + __get_user(se.sigev_notify, &se32->sigev_notify) || + __copy_from_user(&se._sigev_un._pad, &se32->payload, + sizeof(se32->payload)) || + copy_to_user(p, &se, sizeof(se))) + return -EFAULT; + } + return sys_timer_create(clock, p, timer_id); +} + +asmlinkage long +sysn32_rt_sigtimedwait(const sigset_t __user *uthese, + siginfo_t __user *uinfo, + const struct compat_timespec __user *uts32, + size_t sigsetsize) +{ + struct timespec __user *uts = NULL; + + if (uts32) { + struct timespec ts; + uts = compat_alloc_user_space(sizeof(struct timespec)); + if (get_user(ts.tv_sec, &uts32->tv_sec) || + get_user(ts.tv_nsec, &uts32->tv_nsec) || + copy_to_user (uts, &ts, sizeof (ts))) + return -EFAULT; + } + return sys_rt_sigtimedwait(uthese, uinfo, uts, sigsetsize); +} Index: linux/arch/mips/kernel/scall64-o32.S =================================================================== --- linux.orig/arch/mips/kernel/scall64-o32.S 2005-02-13 20:55:57.729574958 -0500 +++ linux/arch/mips/kernel/scall64-o32.S 2005-02-13 21:28:08.199088801 -0500 @@ -316,7 +316,7 @@ sys_call_table: PTR sys_vhangup PTR sys_ni_syscall /* was sys_idle */ PTR sys_ni_syscall /* sys_vm86 */ - PTR sys32_wait4 + PTR compat_sys_wait4 PTR sys_swapoff /* 4115 */ PTR sys32_sysinfo PTR sys32_ipc @@ -459,7 +459,7 @@ sys_call_table: PTR sys_fadvise64_64 PTR compat_sys_statfs64 /* 4255 */ PTR compat_sys_fstatfs64 - PTR sys_timer_create + PTR sys32_timer_create PTR compat_sys_timer_settime PTR compat_sys_timer_gettime PTR sys_timer_getoverrun /* 4260 */ @@ -480,7 +480,7 @@ sys_call_table: PTR compat_sys_mq_notify /* 4275 */ PTR compat_sys_mq_getsetattr PTR sys_ni_syscall /* sys_vserver */ - PTR sys_waitid + PTR sys32_waitid PTR sys_ni_syscall /* available, was setaltroot */ PTR sys_add_key /* 4280 */ PTR sys_request_key Index: linux/arch/mips/kernel/scall64-n32.S =================================================================== --- linux.orig/arch/mips/kernel/scall64-n32.S 2005-02-13 21:26:31.765170354 -0500 +++ linux/arch/mips/kernel/scall64-n32.S 2005-02-13 21:28:08.199088801 -0500 @@ -176,7 +176,7 @@ EXPORT(sysn32_call_table) PTR sys_fork PTR sys32_execve PTR sys_exit - PTR sys32_wait4 + PTR compat_sys_wait4 PTR sys_kill /* 6060 */ PTR sys32_newuname PTR sys_semget @@ -243,8 +243,8 @@ EXPORT(sysn32_call_table) PTR sys_capget PTR sys_capset PTR sys32_rt_sigpending /* 6125 */ - PTR compat_sys_rt_sigtimedwait - PTR sys32_rt_sigqueueinfo + PTR sysn32_rt_sigtimedwait + PTR sys_rt_sigqueueinfo PTR sys32_rt_sigsuspend PTR sys32_sigaltstack PTR compat_sys_utime /* 6130 */ @@ -337,15 +337,15 @@ EXPORT(sysn32_call_table) PTR compat_sys_statfs64 PTR compat_sys_fstatfs64 PTR sys_sendfile64 - PTR sys_timer_create /* 6220 */ - PTR sys_timer_settime - PTR sys_timer_gettime + PTR sys32_timer_create /* 6220 */ + PTR compat_sys_timer_settime + PTR compat_sys_timer_gettime PTR sys_timer_getoverrun PTR sys_timer_delete - PTR sys_clock_settime /* 6225 */ - PTR sys_clock_gettime - PTR sys_clock_getres - PTR sys_clock_nanosleep + PTR compat_sys_clock_settime /* 6225 */ + PTR compat_sys_clock_gettime + PTR compat_sys_clock_getres + PTR compat_sys_clock_nanosleep PTR sys_tgkill PTR compat_sys_utimes /* 6230 */ PTR sys_ni_syscall /* sys_mbind */ @@ -358,7 +358,7 @@ EXPORT(sysn32_call_table) PTR compat_sys_mq_notify PTR compat_sys_mq_getsetattr PTR sys_ni_syscall /* 6240, sys_vserver */ - PTR sys_waitid + PTR sysn32_waitid PTR sys_ni_syscall /* available, was setaltroot */ PTR sys_add_key PTR sys_request_key Index: linux/arch/mips/kernel/signal32.c =================================================================== --- linux.orig/arch/mips/kernel/signal32.c 2005-02-11 10:36:55.000000000 -0500 +++ linux/arch/mips/kernel/signal32.c 2005-02-13 21:28:08.199088801 -0500 @@ -81,8 +81,10 @@ typedef struct compat_siginfo { /* POSIX.1b timers */ struct { - unsigned int _timer1; - unsigned int _timer2; + timer_t _tid; /* timer id */ + int _overrun; /* overrun count */ + sigval_t32 _sigval; /* same as below */ + int _sys_private; /* not to be passed to user */ } _timer; /* POSIX.1b signals */ @@ -416,6 +418,11 @@ int copy_siginfo_to_user32(compat_siginf err |= __copy_to_user(&to->_sifields._pad, &from->_sifields._pad, SI_PAD_SIZE); else { switch (from->si_code >> 16) { + case __SI_TIMER >> 16: + err |= __put_user(from->si_tid, &to->si_tid); + err |= __put_user(from->si_overrun, &to->si_overrun); + err |= __put_user(from->si_int, &to->si_int); + break; case __SI_CHLD >> 16: err |= __put_user(from->si_utime, &to->si_utime); err |= __put_user(from->si_stime, &to->si_stime); @@ -908,3 +915,30 @@ asmlinkage int sys32_rt_sigqueueinfo(int set_fs (old_fs); return ret; } + +asmlinkage long +sys32_waitid(int which, compat_pid_t pid, + compat_siginfo_t __user *uinfo, int options, + struct compat_rusage __user *uru) +{ + siginfo_t info; + struct rusage ru; + long ret; + mm_segment_t old_fs = get_fs(); + + info.si_signo = 0; + set_fs (KERNEL_DS); + ret = sys_waitid(which, pid, (siginfo_t __user *) &info, options, + uru ? (struct rusage __user *) &ru : NULL); + set_fs (old_fs); + + if (ret < 0 || info.si_signo == 0) + return ret; + + if (uru && (ret = put_compat_rusage(&ru, uru))) + return ret; + + BUG_ON(info.si_code & __SI_MASK); + info.si_code |= __SI_CHLD; + return copy_siginfo_to_user32(uinfo, &info); +} Index: linux/arch/mips/kernel/scall32-o32.S =================================================================== --- linux.orig/arch/mips/kernel/scall32-o32.S 2005-02-13 20:55:57.739572561 -0500 +++ linux/arch/mips/kernel/scall32-o32.S 2005-02-13 21:28:08.200088562 -0500 @@ -618,7 +618,7 @@ einval: li v0, -EINVAL sys sys_mq_notify 2 /* 4275 */ sys sys_mq_getsetattr 3 sys sys_ni_syscall 0 /* sys_vserver */ - sys sys_waitid 4 + sys sys_waitid 5 sys sys_ni_syscall 0 /* available, was setaltroot */ sys sys_add_key 5 sys sys_request_key 4 Index: linux/arch/mips/kernel/ptrace32.c =================================================================== --- linux.orig/arch/mips/kernel/ptrace32.c 2005-02-13 20:55:57.740572322 -0500 +++ linux/arch/mips/kernel/ptrace32.c 2005-02-13 21:28:04.328015337 -0500 @@ -277,6 +277,11 @@ asmlinkage int sys32_ptrace(int request, ret = ptrace_detach(child, data); break; + case PTRACE_GETEVENTMSG: + ret = put_user(child->ptrace_message, + (unsigned int __user *) (unsigned long) data); + break; + default: ret = ptrace_request(child, request, addr, data); break; -- Daniel Jacobowitz CodeSourcery, LLC From milang@tal.org Mon Feb 14 13:52:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 13:53:14 +0000 (GMT) Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:38859 "EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 13:52:58 +0000 Received: from tori.tal.org (tori.tal.org [195.16.220.82]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 375C0D906E; Mon, 14 Feb 2005 15:52:54 +0200 (EET) Date: Mon, 14 Feb 2005 15:56:41 +0000 (Local time zone must be set--see zic manual page) From: Kaj-Michael Lang To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] IP22 zilog timeout fix Message-ID: 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: 7247 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: milang@tal.org Precedence: bulk X-list: linux-mips Peter Fuerst posted this fix sometime in December already, but looks like it's not in CVS yet. Without this fix, serial console is impossbile to use as login never shows a prompt and output from userland is also slow. Index: drivers/serial/ip22zilog.c =================================================================== RCS file: /home/cvs/linux/drivers/serial/ip22zilog.c,v retrieving revision 1.16 diff -u -r1.16 ip22zilog.c --- drivers/serial/ip22zilog.c 3 Dec 2004 06:07:38 -0000 1.16 +++ drivers/serial/ip22zilog.c 14 Feb 2005 13:47:08 -0000 @@ -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) -- Kaj-Michael Lang, Turku, Finland milang@tal.org http://www.tal.org/ From milang@tal.org Mon Feb 14 14:04:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 14:04:53 +0000 (GMT) Received: from gw01.mail.saunalahti.fi ([IPv6:::ffff:195.197.172.115]:61402 "EHLO gw01.mail.saunalahti.fi") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 14:04:37 +0000 Received: from tori.tal.org (tori.tal.org [195.16.220.82]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 1A739D90CF; Mon, 14 Feb 2005 16:04:37 +0200 (EET) Date: Mon, 14 Feb 2005 16:08:24 +0000 (Local time zone must be set--see zic manual page) From: Kaj-Michael Lang To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix serial console detection Message-ID: 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: 7248 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: milang@tal.org Precedence: bulk X-list: linux-mips In ip22-setup.c the checks for serial/graphics console logic does not check if ARCS console=g but the machine is using serial console, as it does if no keyboard is attached. This patch adds a check if ConsoleOut is serial. There might also be support for other graphics than Newport soon... Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.44 diff -u -r1.44 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 10 Dec 2004 13:31:42 -0000 1.44 +++ arch/mips/sgi-ip22/ip22-setup.c 14 Feb 2005 13:57:33 -0000 @@ -56,6 +56,7 @@ static int __init ip22_setup(void) { char *ctype; + char *cserial; board_be_init = ip22_be_init; ip22_time_init(); @@ -81,9 +82,14 @@ /* ARCS console environment variable is set to "g?" for * graphics console, it is set to "d" for the first serial * line and "d2" for the second serial line. + * + * Need to check if the case is 'g' but no keyboard: + * (ConsoleIn/Out = serial ) */ ctype = ArcGetEnvironmentVariable("console"); - if (ctype && *ctype == 'd') { + cserial = ArcGetEnvironmentVariable("ConsoleOut"); + + if ( (ctype && *ctype == 'd') || (cserial && *cserial == 's')) { static char options[8]; char *baud = ArcGetEnvironmentVariable("dbaud"); if (baud) @@ -91,7 +97,7 @@ add_preferred_console("ttyS", *(ctype + 1) == '2' ? 1 : 0, baud ? options : NULL); } else if (!ctype || *ctype != 'g') { - /* Use ARC if we don't want serial ('d') or Newport ('g'). */ + /* Use ARC if we don't want serial ('d') or Graphics ('g'). */ prom_flags |= PROM_FLAG_USE_AS_CONSOLE; add_preferred_console("arc", 0, NULL); } -- Kaj-Michael Lang, Turku, Finland milang@tal.org http://www.tal.org/ From ralf@linux-mips.org Mon Feb 14 15:34:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 15:34:51 +0000 (GMT) Received: from p3EE2BD6B.dip.t-dialin.net ([IPv6:::ffff:62.226.189.107]:64336 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 15:34:37 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j1EFYZSA001709 for ; Mon, 14 Feb 2005 16:34:35 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j1EFYZ1k001708 for linux-mips@linux-mips.org; Mon, 14 Feb 2005 16:34:35 +0100 Date: Mon, 14 Feb 2005 16:34:35 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux Message-ID: <20050214153435.GD806@linux-mips.org> References: <20050214035304Z8225242-1340+3175@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050214035304Z8225242-1340+3175@linux-mips.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: 7249 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 14, 2005 at 03:53:03AM +0000, macro@linux-mips.org wrote: > Modified files: > arch/mips64/kernel: Tag: linux_2_4 scall_o32.S > > Log message: > Gas no longer supports redefining macros. Bulletproofing 2.4 against newer tools is something that only makes limited sense, especially wrt. to gcc 3.4 and newer. Chances for any such changes to be accepted upstream are slim - and the kernel has traditionally been easily affected by overoptimization, so I recommend against gcc 3.4. The recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto gcc 3.3 is reasonable and can be considered well tested. Ralf From sjhill@realitydiluted.com Mon Feb 14 15:41:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 15:41:35 +0000 (GMT) Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:8401 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 15:41:20 +0000 Received: from sjhill by real.realitydiluted.com with local (Exim 4.44 #1 (Debian)) id 1D0iLd-0006JN-Le; Mon, 14 Feb 2005 09:41:17 -0600 Subject: Re: CVS Update@linux-mips.org: linux In-Reply-To: <20050214153435.GD806@linux-mips.org> To: Ralf Baechle Date: Mon, 14 Feb 2005 09:41:17 -0600 (CST) CC: linux-mips@linux-mips.org X-Mailer: ELM [version 2.4ME+ PL100 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: From: sjhill@realitydiluted.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: 7250 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 > Bulletproofing 2.4 against newer tools is something that only makes limited > sense, especially wrt. to gcc 3.4 and newer. Chances for any such changes > to be accepted upstream are slim - and the kernel has traditionally been > easily affected by overoptimization, so I recommend against gcc 3.4. The > recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto > gcc 3.3 is reasonable and can be considered well tested. > gcc 3.2 has problems with certain optimizations as well. 3.2 should be used with caution. -Steve From macro@linux-mips.org Mon Feb 14 16:06:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 16:07:05 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:46341 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 16:06:49 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7B7C3F5974; Mon, 14 Feb 2005 17:06:40 +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 21497-10; Mon, 14 Feb 2005 17:06:40 +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 365B8F5945; Mon, 14 Feb 2005 17:06:40 +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 j1EG6hJ4016210; Mon, 14 Feb 2005 17:06:43 +0100 Date: Mon, 14 Feb 2005 16:06:51 +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: <20050214153435.GD806@linux-mips.org> Message-ID: References: <20050214035304Z8225242-1340+3175@linux-mips.org> <20050214153435.GD806@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: 7251 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 On Mon, 14 Feb 2005, Ralf Baechle wrote: > > Modified files: > > arch/mips64/kernel: Tag: linux_2_4 scall_o32.S > > > > Log message: > > Gas no longer supports redefining macros. > > Bulletproofing 2.4 against newer tools is something that only makes limited > sense, especially wrt. to gcc 3.4 and newer. Chances for any such changes > to be accepted upstream are slim - and the kernel has traditionally been > easily affected by overoptimization, so I recommend against gcc 3.4. The > recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto > gcc 3.3 is reasonable and can be considered well tested. I do agree in general, but given that the construct I've used has been supported by gas since 1995, there is no point in keeping our code broken. And binutils actually quite rarely trigger problems with Linux, while they've got improved significantly with the last few releases; unlike with GCC it's normally a good idea to use the latest version of binutils. Maciej From ralf@linux-mips.org Mon Feb 14 18:34:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Feb 2005 18:34:59 +0000 (GMT) Received: from p3EE2BD6B.dip.t-dialin.net ([IPv6:::ffff:62.226.189.107]:59218 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 14 Feb 2005 18:34:43 +0000 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j1EIYf7i004678; Mon, 14 Feb 2005 19:34:41 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j1EIYfP0004677; Mon, 14 Feb 2005 19:34:41 +0100 Date: Mon, 14 Feb 2005 19:34:41 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux Message-ID: <20050214183441.GA4263@linux-mips.org> References: <20050214035304Z8225242-1340+3175@linux-mips.org> <20050214153435.GD806@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: 7252 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 14, 2005 at 04:06:51PM +0000, Maciej W. Rozycki wrote: > > Bulletproofing 2.4 against newer tools is something that only makes limited > > sense, especially wrt. to gcc 3.4 and newer. Chances for any such changes > > to be accepted upstream are slim - and the kernel has traditionally been > > easily affected by overoptimization, so I recommend against gcc 3.4. The > > recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto > > gcc 3.3 is reasonable and can be considered well tested. > > I do agree in general, but given that the construct I've used has been > supported by gas since 1995, there is no point in keeping our code broken. > And binutils actually quite rarely trigger problems with Linux, while > they've got improved significantly with the last few releases; unlike with > GCC it's normally a good idea to use the latest version of binutils. I wasn't objecting to your patch; it's just that I expect some users to upgrade to a recent binutils and gcc at the same time and that has good chances to end up in a nice firework ;-) Ralf From p2@mind.be Tue Feb 15 01:04:49 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 01:05:04 +0000 (GMT) Received: from NAT.office.mind.be ([IPv6:::ffff:62.166.230.82]:57486 "EHLO nat.office.mind.be") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 01:04:49 +0000 Received: from p2 by codecarver with local (Exim 3.36 #1 (Debian)) id 1D0r8y-0004oK-00 for ; Tue, 15 Feb 2005 02:04:48 +0100 Date: Tue, 15 Feb 2005 02:04:48 +0100 To: linux-mips@linux-mips.org Subject: turbo channel drivers for 2.6 Message-ID: <20050215010448.GP3448@mind.be> Mail-Followup-To: peter.de.schrijver@mind.be, linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+gHRqQ1BTyNna/y8" 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: 7253 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 --+gHRqQ1BTyNna/y8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Is there anyone working on a turbo channel driver for 2.6 ? I have 2.4 running on the DEC 3000 (turbo channel alpha machine). I want to get 2.6 to work and it would make sense to share the turbo channel part with other platforms (mipsel, vax). Thanks, Peter (p2). --+gHRqQ1BTyNna/y8 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) iD8DBQFCEUqvKLKVw/RurbsRAuUQAJ9cKei1vUJZ9GlXt1rpMI5osVp+lACfUZKY DTPQGoyFf+o2dSUR3AYa2DQ= =fgg4 -----END PGP SIGNATURE----- --+gHRqQ1BTyNna/y8-- From p.boddupalli@gmail.com Tue Feb 15 06:53:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 06:53:43 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.197]:20583 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 06:53:29 +0000 Received: by rproxy.gmail.com with SMTP id y7so837088rne for ; Mon, 14 Feb 2005 22:53:27 -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=e1jYjrv+cja6FObB5jk9owL81a99nIa/TbAMyA5ZcvjPu4/u0lEEORLmRg/JSZ7fGRQyGZwctBgI3uu0ygCSut4wQd+CFaoual3jCPAnLePry2q30vtQsc1JBeUN1+2MHbNYYwV3t+RRhy3U66D5cdvRfknzKQ6+5FpdpLrRfvI= Received: by 10.38.65.62 with SMTP id n62mr220034rna; Mon, 14 Feb 2005 22:53:27 -0800 (PST) Received: by 10.38.104.29 with HTTP; Mon, 14 Feb 2005 22:53:27 -0800 (PST) Message-ID: Date: Mon, 14 Feb 2005 23:53:27 -0700 From: Prasad Boddupalli Reply-To: Prasad Boddupalli To: linux-mips@linux-mips.org Subject: xgcc for 64-bit machines? 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: 7254 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: p.boddupalli@gmail.com Precedence: bulk X-list: linux-mips Hi, Is the Linux/386 crosscompiler available at http://www.linux-mips.org/wiki/index.php/Toolchains good for 64-bit targets too? thanks, Prasad From eckhardt@satorlaser.com Tue Feb 15 13:36:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 13:36:56 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:20458 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 13:36:33 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D12sP-0003kq-00; Tue, 15 Feb 2005 14:36: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 1D12sP-0005z3-00; Tue, 15 Feb 2005 14:36:29 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] generic framebuffer support, cleanups and buglets with BPP < 32 Date: Tue, 15 Feb 2005 14:39:06 +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: <200502151439.06976.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: 7255 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 Changes: * removed trailing whitespace * use helper function for common bitwise operations * fixed several cases where either the wrong mask was used for bitops or the mask was computed falsely, messing up <32 BPP support * added self-tests for bitcpy_rev() algorithm in module-init function * no need to use explicitly sized integers in some cases * added a few comments where things weren't obvious to me I tested these changes on an Au1100 based board, using the patches to its framebuffer code that were posted here by Christian Pellegrin[1]. I had this code working both on a 16BPP color LCD and a 4BPP monochrome one. Uli [1] http://www.linux-mips.org/archives/linux-mips/2005-01/msg00095.html What happened to those, btw? They at least Work For Me(tm). --- Index: cfbcopyarea.c =================================================================== RCS file: /home/cvs/linux/drivers/video/cfbcopyarea.c,v retrieving revision 1.10 diff -u -r1.10 cfbcopyarea.c --- cfbcopyarea.c 12 Oct 2004 01:45:47 -0000 1.10 +++ cfbcopyarea.c 15 Feb 2005 13:28:02 -0000 @@ -8,18 +8,22 @@ * more details. * * NOTES: - * - * This is for cfb packed pixels. Iplan and such are incorporated in the + * + * This is for cfb packed pixels. Iplan and such are incorporated in the * drivers that need them. - * + * * FIXME - * The code for 24 bit is horrible. It copies byte by byte size instead of - * longs like the other sizes. Needs to be optimized. * - * Also need to add code to deal with cards endians that are different than + * Also need to add code to deal with cards endians that are different than * the native cpu endians. I also need to deal with MSB position in the word. - * + * + * The two functions or copying forward and backward could be split up like + * the ones for filling, i.e. in aligned and unaligned versions. This would + * help moving some redundant computations and branches out of the loop, too. */ + + + #include #include #include @@ -32,53 +36,63 @@ #define LONG_MASK (BITS_PER_LONG - 1) #if BITS_PER_LONG == 32 -#define FB_WRITEL fb_writel -#define FB_READL fb_readl -#define SHIFT_PER_LONG 5 -#define BYTES_PER_LONG 4 +# define FB_WRITEL fb_writel +# define FB_READL fb_readl +# define SHIFT_PER_LONG 5 +# define BYTES_PER_LONG 4 #else -#define FB_WRITEL fb_writeq -#define FB_READL fb_readq -#define SHIFT_PER_LONG 6 -#define BYTES_PER_LONG 8 +# define FB_WRITEL fb_writeq +# define FB_READL fb_readq +# define SHIFT_PER_LONG 6 +# define BYTES_PER_LONG 8 #endif -static void bitcpy(unsigned long __iomem *dst, int dst_idx, - const unsigned long __iomem *src, int src_idx, - unsigned long n) + /* + * Compose two values, using a bitmask as decision value + * This is equivalent to (a & mask) | (b & ~mask) + */ + +static inline unsigned long +comp(unsigned long a, unsigned long b, unsigned long mask) +{ + return ((a ^ b) & mask) ^ b; +} + + /* + * Generic bitwise copy algorithm + */ + +static void +bitcpy(unsigned long __iomem *dst, int dst_idx, + const unsigned long __iomem *src, int src_idx, + unsigned n) { unsigned long first, last; - int shift = dst_idx-src_idx, left, right; - unsigned long d0, d1; - int m; - - if (!n) - return; - - shift = dst_idx-src_idx; + int const shift = dst_idx-src_idx; + int left, right; + first = ~0UL >> dst_idx; last = ~(~0UL >> ((dst_idx+n) % BITS_PER_LONG)); - + if (!shift) { // Same alignment for source and dest - + if (dst_idx+n <= BITS_PER_LONG) { // Single word if (last) first &= last; - FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst); } else { // Multiple destination words + // Leading bits - if (first) { - - FB_WRITEL((FB_READL(src) & first) | - (FB_READL(dst) & ~first), dst); + if (first != ~0UL) { + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst); dst++; src++; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 8) { @@ -94,55 +108,58 @@ } while (n--) FB_WRITEL(FB_READL(src++), dst++); + // Trailing bits if (last) - FB_WRITEL((FB_READL(src) & last) | (FB_READL(dst) & ~last), dst); + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst); } } else { + unsigned long d0, d1; + int m; // Different alignment for source and dest - + right = shift & (BITS_PER_LONG-1); left = -shift & (BITS_PER_LONG-1); - + if (dst_idx+n <= BITS_PER_LONG) { // Single destination word if (last) first &= last; if (shift > 0) { // Single source word - FB_WRITEL(((FB_READL(src) >> right) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp( FB_READL(src) >> right, FB_READL(dst), first), dst); } else if (src_idx+n <= BITS_PER_LONG) { // Single source word - FB_WRITEL(((FB_READL(src) << left) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp(FB_READL(src) << left, FB_READL(dst), first), dst); } else { // 2 source words d0 = FB_READL(src++); d1 = FB_READL(src); - FB_WRITEL(((d0<>right) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp(d0<>right, FB_READL(dst), first), dst); } } else { // Multiple destination words + /** We must always remember the last value read, because in case + SRC and DST overlap bitwise (e.g. when moving just one pixel in + 1bpp), we always collect one full long for DST and that might + overlap with the current long from SRC. We store this value in + 'd0'. */ d0 = FB_READL(src++); // Leading bits if (shift > 0) { // Single source word - FB_WRITEL(((d0 >> right) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp(d0 >> right, FB_READL(dst), first), dst); dst++; n -= BITS_PER_LONG-dst_idx; } else { // 2 source words d1 = FB_READL(src++); - FB_WRITEL(((d0<>right) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp(d0<>right, FB_READL(dst), first), dst); d0 = d1; dst++; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk m = n % BITS_PER_LONG; n /= BITS_PER_LONG; @@ -166,37 +183,34 @@ FB_WRITEL(d0 << left | d1 >> right, dst++); d0 = d1; } - + // Trailing bits if (last) { if (m <= right) { // Single source word - FB_WRITEL(((d0 << left) & last) | - (FB_READL(dst) & ~last), - dst); + FB_WRITEL( comp(d0 << left, FB_READL(dst), last), dst); } else { // 2 source words d1 = FB_READL(src); - FB_WRITEL(((d0<>right) & - last) | (FB_READL(dst) & - ~last), dst); + FB_WRITEL( comp(d0<>right, FB_READL(dst), last), dst); } } } } } -static void bitcpy_rev(unsigned long __iomem *dst, int dst_idx, - const unsigned long __iomem *src, int src_idx, unsigned long n) + /* + * Generic bitwise copy algorithm, operating backward + */ + +static void +bitcpy_rev(unsigned long __iomem *dst, int dst_idx, + const unsigned long __iomem *src, int src_idx, + unsigned n) { unsigned long first, last; - int shift = dst_idx-src_idx, left, right; - unsigned long d0, d1; - int m; - - if (!n) - return; - + int shift; + dst += (n-1)/BITS_PER_LONG; src += (n-1)/BITS_PER_LONG; if ((n-1) % BITS_PER_LONG) { @@ -207,29 +221,31 @@ src += src_idx >> SHIFT_PER_LONG; src_idx &= BITS_PER_LONG-1; } - + shift = dst_idx-src_idx; + first = ~0UL << (BITS_PER_LONG-1-dst_idx); last = ~(~0UL << (BITS_PER_LONG-1-((dst_idx-n) % BITS_PER_LONG))); - + if (!shift) { // Same alignment for source and dest - + if ((unsigned long)dst_idx+1 >= n) { // Single word if (last) first &= last; - FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst); } else { // Multiple destination words + // Leading bits - if (first) { - FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst); + if (first != ~0UL) { + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst); dst--; src--; n -= dst_idx+1; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 8) { @@ -245,56 +261,55 @@ } while (n--) FB_WRITEL(FB_READL(src--), dst--); - + // Trailing bits if (last) - FB_WRITEL((FB_READL(src) & last) | (FB_READL(dst) & ~last), dst); + FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst); } } else { // Different alignment for source and dest - - right = shift & (BITS_PER_LONG-1); - left = -shift & (BITS_PER_LONG-1); - + + int const left = -shift & (BITS_PER_LONG-1); + int const right = shift & (BITS_PER_LONG-1); + if ((unsigned long)dst_idx+1 >= n) { // Single destination word if (last) first &= last; if (shift < 0) { // Single source word - FB_WRITEL((FB_READL(src) << left & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp( FB_READL(src)<= n) { // Single source word - FB_WRITEL(((FB_READL(src) >> right) & first) | - (FB_READL(dst) & ~first), dst); + FB_WRITEL( comp( FB_READL(src)>>right, FB_READL(dst), first), dst); } else { // 2 source words - d0 = FB_READL(src--); - d1 = FB_READL(src); - FB_WRITEL(((d0>>right | d1<>right | FB_READL(src-1)<>right | d1<>right | d1<> right | d1 << left, dst--); d0 = d1; } - + // Trailing bits if (last) { if (m <= left) { // Single source word - FB_WRITEL(((d0 >> right) & last) | - (FB_READL(dst) & ~last), - dst); + FB_WRITEL( comp(d0 >> right, FB_READL(dst), last), dst); } else { // 2 source words d1 = FB_READL(src); - FB_WRITEL(((d0>>right | d1<>right | d1<dx, dy = area->dy, sx = area->sx, sy = area->sy; u32 height = area->height, width = area->width; - int x2, y2, old_dx, old_dy, vxres, vyres; - unsigned long next_line = p->fix.line_length; + int x2, y2, vxres, vyres; + unsigned long const bits_per_line = p->fix.line_length*8u; int dst_idx = 0, src_idx = 0, rev_copy = 0; unsigned long __iomem *dst = NULL, *src = NULL; @@ -352,20 +363,16 @@ /* We want rotation but lack hardware to do it for us. */ if (!p->fbops->fb_rotate && p->var.rotate) { - } - + } + vxres = p->var.xres_virtual; vyres = p->var.yres_virtual; - if (area->dx > vxres || area->sx > vxres || + if (area->dx > vxres || area->sx > vxres || area->dy > vyres || area->sy > vyres) return; - /* clip the destination */ - old_dx = area->dx; - old_dy = area->dy; - - /* + /* clip the destination * We could use hardware clipping but on many cards you get around * hardware clipping by writing to framebuffer directly. */ @@ -378,9 +385,13 @@ width = x2 - dx; height = y2 - dy; + if ((width==0) + ||(height==0)) + return; + /* update sx1,sy1 */ - sx += (dx - old_dx); - sy += (dy - old_dy); + sx += (dx - area->dx); + sy += (dy - area->dy); /* the source must be completely inside the virtual screen */ if (sx < 0 || sy < 0 || @@ -388,45 +399,118 @@ (sy + height) > vyres) return; - if ((dy == sy && dx > sx) || - (dy > sy)) { + /* if the beginning of the target area might overlap with the end of + the source area, be have to copy the area reverse. */ + if ((dy == sy && dx > sx) || + (dy > sy)) { dy += height; sy += height; rev_copy = 1; } - dst = src = (unsigned long __iomem *)((unsigned long)p->screen_base & + // split the base of the framebuffer into a long-aligned address and the + // index of the first bit + dst = src = (unsigned long __iomem *)((unsigned long)p->screen_base & ~(BYTES_PER_LONG-1)); - dst_idx = src_idx = (unsigned long)p->screen_base & (BYTES_PER_LONG-1); - dst_idx += dy*next_line*8 + dx*p->var.bits_per_pixel; - src_idx += sy*next_line*8 + sx*p->var.bits_per_pixel; - + dst_idx = src_idx = 8*((unsigned long)p->screen_base & (BYTES_PER_LONG-1)); + // add offset of source and target area + dst_idx += dy*bits_per_line + dx*p->var.bits_per_pixel; + src_idx += sy*bits_per_line + sx*p->var.bits_per_pixel; + if (p->fbops->fb_sync) p->fbops->fb_sync(p); + if (rev_copy) { while (height--) { - dst_idx -= next_line*8; - src_idx -= next_line*8; + dst_idx -= bits_per_line; + src_idx -= bits_per_line; dst += dst_idx >> SHIFT_PER_LONG; - dst_idx &= (BYTES_PER_LONG-1); + dst_idx &= LONG_MASK; src += src_idx >> SHIFT_PER_LONG; - src_idx &= (BYTES_PER_LONG-1); - bitcpy_rev(dst, dst_idx, src, src_idx, + src_idx &= LONG_MASK; + bitcpy_rev(dst, dst_idx, src, src_idx, width*p->var.bits_per_pixel); - } + } } else { while (height--) { dst += dst_idx >> SHIFT_PER_LONG; - dst_idx &= (BYTES_PER_LONG-1); + dst_idx &= LONG_MASK; src += src_idx >> SHIFT_PER_LONG; - src_idx &= (BYTES_PER_LONG-1); - bitcpy(dst, dst_idx, src, src_idx, + src_idx &= LONG_MASK; + bitcpy(dst, dst_idx, src, src_idx, width*p->var.bits_per_pixel); - dst_idx += next_line*8; - src_idx += next_line*8; - } + dst_idx += bits_per_line; + src_idx += bits_per_line; + } + } +} +#undef CFB_DEBUG +#ifdef CFB_DEBUG +/** all this init-function does is to perform a few unittests. +The idea it always to invoke the function to test on a predefined bitmap and +compare the results to the expected output. +TODO: + - this currently only tests bitcpy_rev, as that was the only one giving me trouble + - this assumes 32 bit longs + - not sure about endianess, I only tested this on a 32 bit MIPS little endian system + - could reuse testcases to test forward copying, too, just reverse the operation +*/ +int __init cfb_copyarea_init(void) +{ + char const* comment = 0; + printk( KERN_INFO "cfb_copyarea_init()\n"); + { + comment = "copy a single u32, source and target u32-aligned"; + u32 tmp[] = { 0xaaaaaaaau, 0x55555555u, 0xffffffffu, 0x00000000u }; + u32 const expect[] = { 0xaaaaaaaau, 0xaaaaaaaau, 0xffffffffu, 0x00000000u }; + + bitcpy_rev( tmp, 0, tmp+1, 0, 32); + + if( 0!=memcmp( expect, tmp, sizeof tmp)) + goto error; + } + + { + comment = "copy a single u32, source u32-aligned"; + u32 tmp[] = { 0x11112222u, 0x33334444u, 0x55556666u, 0x77778888u }; + u32 const expect[] = { 0x11112222u, 0x22224444u, 0x55551111u, 0x77778888u }; + + bitcpy_rev( tmp, 0, tmp+1, 16, 32); + + if( 0!=memcmp( expect, tmp, sizeof tmp)) + goto error; + } + + { + comment = "copy a single u32, target u32-aligned"; + u32 tmp[] = { 0x11112222u, 0x33334444u, 0x55556666u, 0x77778888u }; + u32 const expect[] = { 0x11112222u, 0x33334444u, 0x44441111u, 0x77778888u }; + + bitcpy_rev( tmp, 16, tmp+2, 0, 32); + + if( 0!=memcmp( expect, tmp, sizeof tmp)) + goto error; } + + { + comment = "copy two u32, source and target u32-aligned"; + u32 tmp[] = { 0xaaaaaaaau, 0x55555555u, 0xffffffffu, 0x00000000u }; + u32 const expect[] = { 0xaaaaaaaau, 0xaaaaaaaau, 0x55555555u, 0x00000000u }; + + bitcpy_rev( tmp, 0, tmp+1, 0, 64); + + if( 0!=memcmp( expect, tmp, sizeof tmp)) + goto error; + } + + return 0; + +error: + printk( KERN_ERR " framebuffer self-test(%s) failed\n", comment); + return -1; } +module_init(cfb_copyarea_init); +#endif EXPORT_SYMBOL(cfb_copyarea); Index: cfbfillrect.c =================================================================== RCS file: /home/cvs/linux/drivers/video/cfbfillrect.c,v retrieving revision 1.8 diff -u -r1.8 cfbfillrect.c --- cfbfillrect.c 12 Oct 2004 01:45:47 -0000 1.8 +++ cfbfillrect.c 15 Feb 2005 13:28:02 -0000 @@ -1,7 +1,7 @@ /* - * Generic fillrect for frame buffers with packed pixels of any depth. + * Generic fillrect for frame buffers with packed pixels of any depth. * - * Copyright (C) 2000 James Simmons (jsimmons@linux-fbdev.org) + * Copyright (C) 2000 James Simmons (jsimmons@linux-fbdev.org) * * 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 @@ -9,8 +9,8 @@ * * NOTES: * - * The code for depths like 24 that don't have integer number of pixels per - * long is broken and needs to be fixed. For now I turned these types of + * The code for depths like 24 that don't have integer number of pixels per + * long is broken and needs to be fixed. For now I turned these types of * mode off. * * Also need to add code to deal with cards endians that are different than @@ -24,149 +24,134 @@ #include #if BITS_PER_LONG == 32 -#define FB_WRITEL fb_writel -#define FB_READL fb_readl -#define BYTES_PER_LONG 4 -#define SHIFT_PER_LONG 5 +# define FB_WRITEL fb_writel +# define FB_READL fb_readl +# define SHIFT_PER_LONG 5 +# define BYTES_PER_LONG 4 #else -#define FB_WRITEL fb_writeq -#define FB_READL fb_readq -#define BYTES_PER_LONG 8 -#define SHIFT_PER_LONG 6 +# define FB_WRITEL fb_writeq +# define FB_READL fb_readq +# define SHIFT_PER_LONG 6 +# define BYTES_PER_LONG 8 #endif -#define EXP1(x) 0xffffffffU*x -#define EXP2(x) 0x55555555U*x -#define EXP4(x) 0x11111111U*0x ## x - -typedef u32 pixel_t; - -static const u32 bpp1tab[2] = { - EXP1(0), EXP1(1) -}; - -static const u32 bpp2tab[4] = { - EXP2(0), EXP2(1), EXP2(2), EXP2(3) -}; - -static const u32 bpp4tab[16] = { - EXP4(0), EXP4(1), EXP4(2), EXP4(3), EXP4(4), EXP4(5), EXP4(6), EXP4(7), - EXP4(8), EXP4(9), EXP4(a), EXP4(b), EXP4(c), EXP4(d), EXP4(e), EXP4(f) -}; - /* * Compose two values, using a bitmask as decision value * This is equivalent to (a & mask) | (b & ~mask) */ -static inline unsigned long comp(unsigned long a, unsigned long b, - unsigned long mask) +static inline unsigned long +comp(unsigned long a, unsigned long b, unsigned long mask) { return ((a ^ b) & mask) ^ b; } -static inline u32 pixel_to_pat32(const struct fb_info *p, pixel_t pixel) -{ - u32 pat = pixel; + /* + * Create a pattern with the given pixel's color + */ - switch (p->var.bits_per_pixel) { +#if BITS_PER_LONG == 64 +static inline unsigned long +pixel_to_pat( u32 bpp, u32 pixel) +{ + switch (bpp) { case 1: - pat = bpp1tab[pat]; - break; - + return 0xfffffffffffffffful*pixel; case 2: - pat = bpp2tab[pat]; - break; - + return 0x5555555555555555ul*pixel; case 4: - pat = bpp4tab[pat]; - break; - + return 0x1111111111111111ul*pixel; case 8: - pat |= pat << 8; - // Fall through + return 0x0101010101010101ul*pixel; + case 12: + return 0x0001001001001001ul*pixel; case 16: - pat |= pat << 16; - // Fall through + return 0x0001000100010001ul*pixel; + case 24: + return 0x0000000001000001ul*pixel; case 32: - break; + return 0x0000000100000001ul*pixel; + default: + panic("pixel_to_pat(): unsupported pixelformat\n"); } - return pat; } - - /* - * Expand a pixel value to a generic 32/64-bit pattern and rotate it to - * the correct start position - */ - -static inline unsigned long pixel_to_pat(const struct fb_info *p, - pixel_t pixel, int left) +#else +static inline unsigned long +pixel_to_pat( u32 bpp, u32 pixel) { - unsigned long pat = pixel; - u32 bpp = p->var.bits_per_pixel; - int i; - - /* expand pixel value */ - for (i = bpp; i < BITS_PER_LONG; i *= 2) - pat |= pat << i; - - /* rotate pattern to correct start position */ - pat = pat << left | pat >> (bpp-left); - return pat; + switch (bpp) { + case 1: + return 0xfffffffful*pixel; + case 2: + return 0x55555555ul*pixel; + case 4: + return 0x11111111ul*pixel; + case 8: + return 0x01010101ul*pixel; + case 12: + return 0x00001001ul*pixel; + case 16: + return 0x00010001ul*pixel; + case 24: + return 0x00000001ul*pixel; + case 32: + return 0x00000001ul*pixel; + default: + panic("pixel_to_pat(): unsupported pixelformat\n"); + } } +#endif /* - * Unaligned 32-bit pattern fill using 32/64-bit memory accesses + * Aligned pattern fill using 32/64-bit memory accesses */ -void bitfill32(unsigned long __iomem *dst, int dst_idx, u32 pat, u32 n) +static void +bitfill32(unsigned long __iomem *dst, int dst_idx, unsigned long pat, unsigned n) { - unsigned long val = pat; unsigned long first, last; - + if (!n) return; - -#if BITS_PER_LONG == 64 - val |= val << 32; -#endif - + first = ~0UL >> dst_idx; last = ~(~0UL >> ((dst_idx+n) % BITS_PER_LONG)); - + + if (dst_idx+n <= BITS_PER_LONG) { // Single word if (last) first &= last; - FB_WRITEL(comp(val, FB_READL(dst), first), dst); + FB_WRITEL(comp(pat, FB_READL(dst), first), dst); } else { // Multiple destination words + // Leading bits - if (first) { - FB_WRITEL(comp(val, FB_READL(dst), first), dst); + if (first!= ~0UL) { + FB_WRITEL(comp(pat, FB_READL(dst), first), dst); dst++; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 8) { - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); - FB_WRITEL(val, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); + FB_WRITEL(pat, dst++); n -= 8; } while (n--) - FB_WRITEL(val, dst++); - + FB_WRITEL(pat, dst++); + // Trailing bits if (last) - FB_WRITEL(comp(val, FB_READL(dst), first), dst); + FB_WRITEL(comp(pat, FB_READL(dst), last), dst); } } @@ -178,17 +163,18 @@ * used for the next 32/64-bit word */ -void bitfill(unsigned long __iomem *dst, int dst_idx, unsigned long pat, int left, - int right, u32 n) +static void +bitfill(unsigned long __iomem *dst, int dst_idx, unsigned long pat, int left, + int right, unsigned n) { unsigned long first, last; if (!n) return; - + first = ~0UL >> dst_idx; last = ~(~0UL >> ((dst_idx+n) % BITS_PER_LONG)); - + if (dst_idx+n <= BITS_PER_LONG) { // Single word if (last) @@ -203,7 +189,7 @@ pat = pat << left | pat >> right; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 4) { @@ -221,28 +207,28 @@ FB_WRITEL(pat, dst++); pat = pat << left | pat >> right; } - + // Trailing bits if (last) FB_WRITEL(comp(pat, FB_READL(dst), first), dst); } } -void bitfill32_rev(unsigned long __iomem *dst, int dst_idx, u32 pat, u32 n) + /* + * Aligned pattern invert using 32/64-bit memory accesses + */ +static void +bitfill32_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat, unsigned n) { unsigned long val = pat, dat; unsigned long first, last; - + if (!n) return; - -#if BITS_PER_LONG == 64 - val |= val << 32; -#endif - + first = ~0UL >> dst_idx; last = ~(~0UL >> ((dst_idx+n) % BITS_PER_LONG)); - + if (dst_idx+n <= BITS_PER_LONG) { // Single word if (last) @@ -252,13 +238,13 @@ } else { // Multiple destination words // Leading bits - if (first) { + if (first!=0UL) { dat = FB_READL(dst); FB_WRITEL(comp(dat ^ val, dat, first), dst); dst++; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 8) { @@ -283,34 +269,35 @@ while (n--) { FB_WRITEL(FB_READL(dst) ^ val, dst); dst++; - } + } // Trailing bits if (last) { dat = FB_READL(dst); - FB_WRITEL(comp(dat ^ val, dat, first), dst); + FB_WRITEL(comp(dat ^ val, dat, last), dst); } } } /* - * Unaligned generic pattern fill using 32/64-bit memory accesses + * Unaligned generic pattern invert using 32/64-bit memory accesses * The pattern must have been expanded to a full 32/64-bit value * Left/right are the appropriate shifts to convert to the pattern to be * used for the next 32/64-bit word */ -void bitfill_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat, int left, - int right, u32 n) +static void +bitfill_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat, int left, + int right, unsigned n) { unsigned long first, last, dat; if (!n) return; - + first = ~0UL >> dst_idx; last = ~(~0UL >> ((dst_idx+n) % BITS_PER_LONG)); - + if (dst_idx+n <= BITS_PER_LONG) { // Single word if (last) @@ -319,15 +306,16 @@ FB_WRITEL(comp(dat ^ pat, dat, first), dst); } else { // Multiple destination words + // Leading bits - if (first) { + if (first != 0UL) { dat = FB_READL(dst); FB_WRITEL(comp(dat ^ pat, dat, first), dst); dst++; pat = pat << left | pat >> right; n -= BITS_PER_LONG-dst_idx; } - + // Main chunk n /= BITS_PER_LONG; while (n >= 4) { @@ -350,11 +338,11 @@ dst++; pat = pat << left | pat >> right; } - + // Trailing bits if (last) { dat = FB_READL(dst); - FB_WRITEL(comp(dat ^ pat, dat, first), dst); + FB_WRITEL(comp(dat ^ pat, dat, last), dst); } } } @@ -365,6 +353,7 @@ unsigned long x2, y2, vxres, vyres; unsigned long height, width, fg; unsigned long __iomem *dst; + unsigned long pat; int dst_idx, left; if (p->state != FBINFO_STATE_RUNNING) @@ -372,32 +361,34 @@ /* We want rotation but lack hardware to do it for us. */ if (!p->fbops->fb_rotate && p->var.rotate) { - } - + } + vxres = p->var.xres_virtual; vyres = p->var.yres_virtual; - if (!rect->width || !rect->height || + if (!rect->width || !rect->height || rect->dx > vxres || rect->dy > vyres) return; /* We could use hardware clipping but on many cards you get around * hardware clipping by writing to framebuffer directly. */ - + x2 = rect->dx + rect->width; y2 = rect->dy + rect->height; x2 = x2 < vxres ? x2 : vxres; y2 = y2 < vyres ? y2 : vyres; width = x2 - rect->dx; height = y2 - rect->dy; - + if (p->fix.visual == FB_VISUAL_TRUECOLOR || p->fix.visual == FB_VISUAL_DIRECTCOLOR ) fg = ((u32 *) (p->pseudo_palette))[rect->color]; else fg = rect->color; - - dst = (unsigned long __iomem *)((unsigned long)p->screen_base & + + pat = pixel_to_pat( bpp, fg); + + dst = (unsigned long __iomem *)((unsigned long)p->screen_base & ~(BYTES_PER_LONG-1)); dst_idx = ((unsigned long)p->screen_base & (BYTES_PER_LONG-1))*8; dst_idx += rect->dy*p->fix.line_length*8+rect->dx*bpp; @@ -406,16 +397,18 @@ if (p->fbops->fb_sync) p->fbops->fb_sync(p); if (!left) { - u32 pat = pixel_to_pat32(p, fg); - void (*fill_op32)(unsigned long __iomem *dst, int dst_idx, u32 pat, - u32 n) = NULL; - + void (*fill_op32)(unsigned long __iomem *dst, int dst_idx, + unsigned long pat, unsigned n) = NULL; + switch (rect->rop) { case ROP_XOR: fill_op32 = bitfill32_rev; break; case ROP_COPY: + fill_op32 = bitfill32; + break; default: + printk( KERN_ERR "cfb_fillrect(): unknown rop, defaulting to ROP_COPY\n"); fill_op32 = bitfill32; break; } @@ -426,26 +419,33 @@ dst_idx += p->fix.line_length*8; } } else { - unsigned long pat = pixel_to_pat(p, fg, (left-dst_idx) % bpp); + int rot = (left-dst_idx) % bpp; + + /* rotate pattern to correct start position */ + pat = pat << rot | pat >> (bpp-rot); + int right = bpp-left; int r; - void (*fill_op)(unsigned long __iomem *dst, int dst_idx, - unsigned long pat, int left, int right, - u32 n) = NULL; - + void (*fill_op)(unsigned long __iomem *dst, int dst_idx, + unsigned long pat, int left, int right, + unsigned n) = NULL; + switch (rect->rop) { case ROP_XOR: fill_op = bitfill_rev; break; case ROP_COPY: + fill_op = bitfill; + break; default: + printk( KERN_ERR "cfb_fillrect(): unknown rop, defaulting to ROP_COPY\n"); fill_op = bitfill; break; } while (height--) { dst += dst_idx >> SHIFT_PER_LONG; dst_idx &= (BITS_PER_LONG-1); - fill_op(dst, dst_idx, pat, left, right, + fill_op(dst, dst_idx, pat, left, right, width*bpp); r = (p->fix.line_length*8) % bpp; pat = pat << (bpp-r) | pat >> r; From eckhardt@satorlaser.com Tue Feb 15 14:24:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 14:24:44 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.190]:18154 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 14:24:29 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D13cq-0000km-00; Tue, 15 Feb 2005 15:24:28 +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 1D13cp-0001Fo-00; Tue, 15 Feb 2005 15:24:28 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] support for DP83847 MII Date: Tue, 15 Feb 2005 15:27:06 +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: <200502151527.06486.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: 7256 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 DP83847, from National Semiconductors. The patch changes four things in fact: * add support for DP83847 MII * remove unused variable * add some initialisations so even an unknown MII won't result in a crash * correct error message to "no known MIIs found" Uli --- Index: au1000_eth.c =================================================================== RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v retrieving revision 1.41 diff -u -w -r1.41 au1000_eth.c --- au1000_eth.c 10 Jan 2005 10:26:25 -0000 1.41 +++ au1000_eth.c 15 Feb 2005 14:22:06 -0000 @@ -151,13 +151,6 @@ SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \ SUPPORTED_Autoneg -static char *phy_link[] = -{ "unknown", - "10Base2", "10BaseT", - "AUI", - "100BaseT", "100BaseTX", "100BaseFX" -}; - int bcm_5201_init(struct net_device *dev, int phy_addr) { s16 data; @@ -785,6 +778,7 @@ {"Broadcom BCM5201 10/100 BaseT PHY",0x0040,0x6212, &bcm_5201_ops,0}, {"Broadcom BCM5221 10/100 BaseT PHY",0x0040,0x61e4, &bcm_5201_ops,0}, {"Broadcom BCM5222 10/100 BaseT PHY",0x0040,0x6322, &bcm_5201_ops,1}, + {"NS DP83847 PHY", 0x2000, 0x5c30, &bcm_5201_ops ,0}, {"AMD 79C901 HomePNA PHY",0x0000,0x35c8, &am79c901_ops,0}, {"AMD 79C874 10/100 BaseT PHY",0x0022,0x561b, &am79c874_ops,0}, {"LSI 80227 10/100 BaseT PHY",0x0016,0xf840, &lsi_80227_ops,0}, @@ -1045,7 +1039,7 @@ #endif if (aup->mii->chip_info == NULL) { - printk(KERN_ERR "%s: Au1x No MII transceivers found!\n", + printk(KERN_ERR "%s: Au1x No known MII transceivers found!\n", dev->name); return -1; } @@ -1546,6 +1540,9 @@ printk(KERN_ERR "%s: out of memory\n", dev->name); goto err_out; } + aup->mii->next = NULL; + aup->mii->chip_info = NULL; + aup->mii->status = 0; aup->mii->mii_control_reg = 0; aup->mii->mii_data_reg = 0; From macro@linux-mips.org Tue Feb 15 14:53:11 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 14:53:26 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:55309 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 14:53:11 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 139D7F5974; Tue, 15 Feb 2005 15:53:00 +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 15444-08; Tue, 15 Feb 2005 15:52:59 +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 DF517E1D10; Tue, 15 Feb 2005 15:52:59 +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 j1FEr2tU011526; Tue, 15 Feb 2005 15:53:02 +0100 Date: Tue, 15 Feb 2005 14:53:10 +0000 (GMT) From: "Maciej W. Rozycki" To: "Peter 'p2' De Schrijver" Cc: linux-mips@linux-mips.org Subject: Re: turbo channel drivers for 2.6 In-Reply-To: <20050215010448.GP3448@mind.be> Message-ID: References: <20050215010448.GP3448@mind.be> 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: 7257 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 On Tue, 15 Feb 2005, Peter 'p2' De Schrijver wrote: > Is there anyone working on a turbo channel driver for 2.6 ? I have 2.4 I am, halfheartedly. Have you seen James Simmons's work? > running on the DEC 3000 (turbo channel alpha machine). I want to get 2.6 > to work and it would make sense to share the turbo channel part with > other platforms (mipsel, vax). That's the only reasonable way of doing it. It should also permit easy support for multi-bus peripheral device drivers, namely for: DEFTA/DEFEA/DEFPA, PMAGD/PBXGA and DGLTA/DGLPB. Maciej From eckhardt@satorlaser.com Tue Feb 15 16:12:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 16:12:48 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.191]:51410 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 16:12:29 +0000 Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D15JM-0005k0-00; Tue, 15 Feb 2005 17:12:28 +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 1D15JL-0001Es-00; Tue, 15 Feb 2005 17:12:27 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] cleanup and two new LCD panels Date: Tue, 15 Feb 2005 17:15:06 +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: <200502151715.07181.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: 7258 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 Changes: * add documentation to the macros that describe the registers of the LCD controller * replace ad-hoc uint32 typedef with common u32 * convert the table with LCD driver data to use new-style initialisers * added driver data for two more displays * replace the fixed-size panel_name field with a plain string Apart from the changes to the table, this should not result in any observable change, it is mostly cosmetic. A question that came up hacking this, concerning registers of devices in general: is there a reason not to use bitfields for those? I find it much clearer and more expressive when doing bit-fiddling than lots of bitwise ops. Uli --- Index: drivers/video/au1100fb.h =================================================================== RCS file: /home/cvs/linux/drivers/video/au1100fb.h,v retrieving revision 1.1 diff -u -r1.1 au1100fb.h --- drivers/video/au1100fb.h 14 Jul 2002 21:33:34 -0000 1.1 +++ drivers/video/au1100fb.h 15 Feb 2005 15:57:28 -0000 @@ -31,22 +31,27 @@ #define _AU1100LCD_H /********************************************************************/ -#define uint32 unsigned long + typedef volatile struct { - uint32 lcd_control; - uint32 lcd_intstatus; - uint32 lcd_intenable; - uint32 lcd_horztiming; - uint32 lcd_verttiming; - uint32 lcd_clkcontrol; - uint32 lcd_dmaaddr0; - uint32 lcd_dmaaddr1; - uint32 lcd_words; - uint32 lcd_pwmdiv; - uint32 lcd_pwmhi; - uint32 reserved[(0x0400-0x002C)/4]; - uint32 lcd_pallettebase[256]; + u32 lcd_control; + u32 lcd_intstatus; + u32 lcd_intenable; + u32 lcd_horztiming; + u32 lcd_verttiming; + u32 lcd_clkcontrol; + /* physical address of the framebuffer */ + u32 lcd_dmaaddr0; + u32 lcd_dmaaddr1; + /* number of words + 0/180 degree swivel: in the framebuffer + 90/270 degree swivel: per line + minus one. */ + u32 lcd_words; + u32 lcd_pwmdiv; + u32 lcd_pwmhi; + u32 reserved[(0x0400-0x002C)/4]; + u32 lcd_pallettebase[256]; } AU1100_LCD; @@ -59,31 +64,45 @@ */ /* lcd_control */ + +/* Sixten Bit Per Pixel Format */ #define LCD_CONTROL_SBPPF (7<<18) #define LCD_CONTROL_SBPPF_655 (0<<18) #define LCD_CONTROL_SBPPF_565 (1<<18) #define LCD_CONTROL_SBPPF_556 (2<<18) #define LCD_CONTROL_SBPPF_1555 (3<<18) #define LCD_CONTROL_SBPPF_5551 (4<<18) +/* White data Polarity */ #define LCD_CONTROL_WP (1<<17) +/* White Data enable */ #define LCD_CONTROL_WD (1<<16) +/* Coherent */ #define LCD_CONTROL_C (1<<15) +/* Swivel Mode */ #define LCD_CONTROL_SM (3<<13) #define LCD_CONTROL_SM_0 (0<<13) #define LCD_CONTROL_SM_90 (1<<13) #define LCD_CONTROL_SM_180 (2<<13) #define LCD_CONTROL_SM_270 (3<<13) +/* Data Bits (0=16, 1=12) */ #define LCD_CONTROL_DB (1<<12) +/* Colour Channel Operation (0=RGB, 1=BGR) */ #define LCD_CONTROL_CCO (1<<11) +/* Dual Panel */ #define LCD_CONTROL_DP (1<<10) +/* Pixel Order */ #define LCD_CONTROL_PO (3<<8) #define LCD_CONTROL_PO_00 (0<<8) #define LCD_CONTROL_PO_01 (1<<8) #define LCD_CONTROL_PO_10 (2<<8) #define LCD_CONTROL_PO_11 (3<<8) +/* Monochrome Panel Interface */ #define LCD_CONTROL_MPI (1<<7) +/* Panel Type (0=STN passive, 1=LCD active) */ #define LCD_CONTROL_PT (1<<6) +/* Panel Colour (0=monochrome, 1=coloured) */ #define LCD_CONTROL_PC (1<<5) +/* Bits Per Pixel */ #define LCD_CONTROL_BPP (7<<1) #define LCD_CONTROL_BPP_1 (0<<1) #define LCD_CONTROL_BPP_2 (1<<1) @@ -91,71 +110,102 @@ #define LCD_CONTROL_BPP_8 (3<<1) #define LCD_CONTROL_BPP_12 (4<<1) #define LCD_CONTROL_BPP_16 (5<<1) +/* GO (enable display controller)*/ #define LCD_CONTROL_GO (1<<0) /* lcd_intstatus, lcd_intenable */ +/* ShutDown */ #define LCD_INT_SD (1<<7) +/* OverFlow */ #define LCD_INT_OF (1<<6) +/* UnderFlow */ #define LCD_INT_UF (1<<5) +/* Start Active */ #define LCD_INT_SA (1<<3) +/* Start Sync */ #define LCD_INT_SS (1<<2) +/* Start address 1 latched */ #define LCD_INT_S1 (1<<1) +/* Start address 0 latched */ #define LCD_INT_S0 (1<<0) /* lcd_horztiming */ +/* Horizontal Nondisplay period 2 */ #define LCD_HORZTIMING_HN2 (255<<24) #define LCD_HORZTIMING_HN2_N(N) (((N)-1)<<24) +/* Horizontal Nondisplay period 2 */ #define LCD_HORZTIMING_HN1 (255<<16) #define LCD_HORZTIMING_HN1_N(N) (((N)-1)<<16) +/* Horizontal sync Pulse Width */ #define LCD_HORZTIMING_HPW (63<<10) #define LCD_HORZTIMING_HPW_N(N) (((N)-1)<<10) +/* Pixels Per Line */ #define LCD_HORZTIMING_PPL (1023<<0) #define LCD_HORZTIMING_PPL_N(N) (((N)-1)<<0) /* lcd_verttiming */ +/* Vertical Nondisplay period 2 */ #define LCD_VERTTIMING_VN2 (255<<24) #define LCD_VERTTIMING_VN2_N(N) (((N)-1)<<24) +/* Vertical Nondisplay period 1 */ #define LCD_VERTTIMING_VN1 (255<<16) #define LCD_VERTTIMING_VN1_N(N) (((N)-1)<<16) +/* Vertical sync Pulse Width */ #define LCD_VERTTIMING_VPW (63<<10) #define LCD_VERTTIMING_VPW_N(N) (((N)-1)<<10) +/* Lines Per Panel */ #define LCD_VERTTIMING_LPP (1023<<0) #define LCD_VERTTIMING_LPP_N(N) (((N)-1)<<0) /* lcd_clkcontrol */ +/* Invert Bias */ #define LCD_CLKCONTROL_IB (1<<18) +/* Invert pixelClock */ #define LCD_CLKCONTROL_IC (1<<17) +/* Invert Horizontal (line) clock */ #define LCD_CLKCONTROL_IH (1<<16) +/* Invert Vertical (frame) clock */ #define LCD_CLKCONTROL_IV (1<<15) +/* Bias signal Frequency */ #define LCD_CLKCONTROL_BF (31<<10) #define LCD_CLKCONTROL_BF_N(N) (((N)-1)<<10) +/* Pixel Clock Divisor */ #define LCD_CLKCONTROL_PCD (1023<<0) #define LCD_CLKCONTROL_PCD_N(N) ((N)<<0) /* lcd_pwmdiv */ +/* Enable */ #define LCD_PWMDIV_EN (1<<12) +/* PWM frequency DIVider */ #define LCD_PWMDIV_PWMDIV (2047<<0) #define LCD_PWMDIV_PWMDIV_N(N) (((N)-1)<<0) /* lcd_pwmhi */ +/* PWM HIgh time for clock 1 */ #define LCD_PWMHI_PWMHI1 (2047<<12) #define LCD_PWMHI_PWMHI1_N(N) ((N)<<12) +/* PWM HIgh time for clock 0 */ #define LCD_PWMHI_PWMHI0 (2047<<0) #define LCD_PWMHI_PWMHI0_N(N) ((N)<<0) /* lcd_pallettebase - MONOCHROME */ +/* Monochromatic panel Intensity */ #define LCD_PALLETTE_MONO_MI (15<<0) #define LCD_PALLETTE_MONO_MI_N(N) ((N)<<0) /* lcd_pallettebase - COLOR */ +/* Blue Intensity (if not LCD_CONTROL_CCO set) */ #define LCD_PALLETTE_COLOR_BI (15<<8) #define LCD_PALLETTE_COLOR_BI_N(N) ((N)<<8) +/* Green Intensity */ #define LCD_PALLETTE_COLOR_GI (15<<4) #define LCD_PALLETTE_COLOR_GI_N(N) ((N)<<4) +/* Red Intensity (if not LCD_CONTROL_CCO set) */ #define LCD_PALLETTE_COLOR_RI (15<<0) #define LCD_PALLETTE_COLOR_RI_N(N) ((N)<<0) /* lcd_palletebase - COLOR TFT PALLETIZED */ +/* Direct Color (layout defined by LCD_CONTROL_SBPPF) */ #define LCD_PALLETTE_TFT_DC (65535<<0) #define LCD_PALLETTE_TFT_DC_N(N) ((N)<<0) @@ -163,219 +213,190 @@ struct known_lcd_panels { - uint32 xres; - uint32 yres; - uint32 bpp; - unsigned char panel_name[256]; - uint32 mode_control; - uint32 mode_horztiming; - uint32 mode_verttiming; - uint32 mode_clkcontrol; - uint32 mode_pwmdiv; - uint32 mode_pwmhi; - uint32 mode_toyclksrc; - uint32 mode_backlight; - + u32 xres; + u32 yres; + u32 bpp; + char const* panel_name; + u32 mode_control; + u32 mode_horztiming; + u32 mode_verttiming; + u32 mode_clkcontrol; + u32 mode_pwmdiv; + u32 mode_pwmhi; + u32 mode_toyclksrc; + u32 mode_backlight; }; #if defined(__BIG_ENDIAN) -#define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_11 +# define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_11 #else -#define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_00 +# define LCD_DEFAULT_PIX_FORMAT LCD_CONTROL_PO_00 #endif /* * The fb driver assumes that AUX PLL is at 48MHz. That can * cover up to 800x600 resolution; if you need higher resolution, * you should modify the driver as needed, not just this structure. + * + * TODO: + * - decode the magic numbers below using the macros above + * - provide/include and use macros for mode_toyclksrc */ struct known_lcd_panels panels[] = { - { /* 0: Pb1100 LCDA: Sharp 320x240 TFT panel */ - 320, /* xres */ - 240, /* yres */ - 16, /* bpp */ - - "Sharp_320x240_16", - /* mode_control */ - ( LCD_CONTROL_SBPPF_565 - /*LCD_CONTROL_WP*/ - /*LCD_CONTROL_WD*/ - | LCD_CONTROL_C - | LCD_CONTROL_SM_0 - /*LCD_CONTROL_DB*/ - /*LCD_CONTROL_CCO*/ - /*LCD_CONTROL_DP*/ - | LCD_DEFAULT_PIX_FORMAT - /*LCD_CONTROL_MPI*/ - | LCD_CONTROL_PT - | LCD_CONTROL_PC - | LCD_CONTROL_BPP_16 ), - - /* mode_horztiming */ - ( LCD_HORZTIMING_HN2_N(8) - | LCD_HORZTIMING_HN1_N(60) - | LCD_HORZTIMING_HPW_N(12) - | LCD_HORZTIMING_PPL_N(320) ), - - /* mode_verttiming */ - ( LCD_VERTTIMING_VN2_N(5) - | LCD_VERTTIMING_VN1_N(17) - | LCD_VERTTIMING_VPW_N(1) - | LCD_VERTTIMING_LPP_N(240) ), - - /* mode_clkcontrol */ - ( 0 - /*LCD_CLKCONTROL_IB*/ - /*LCD_CLKCONTROL_IC*/ - /*LCD_CLKCONTROL_IH*/ - /*LCD_CLKCONTROL_IV*/ - | LCD_CLKCONTROL_PCD_N(1) ), - - /* mode_pwmdiv */ - 0, - - /* mode_pwmhi */ - 0, - - /* mode_toyclksrc */ - ((1<<7) | (1<<6) | (1<<5)), - - /* mode_backlight */ - 6 + { /* Pb1100 LCDA: Sharp 320x240 TFT panel */ + .xres = 320, + .yres = 240, + .bpp = 16, + .panel_name = "Sharp_320x240_16", + .mode_control = + ( LCD_CONTROL_SBPPF_565 + | LCD_CONTROL_C + | LCD_CONTROL_SM_0 + | LCD_DEFAULT_PIX_FORMAT + | LCD_CONTROL_PT + | LCD_CONTROL_PC + | LCD_CONTROL_BPP_16 ), + .mode_horztiming = + ( LCD_HORZTIMING_HN2_N(8) + | LCD_HORZTIMING_HN1_N(60) + | LCD_HORZTIMING_HPW_N(12) + | LCD_HORZTIMING_PPL_N(320) ), + .mode_verttiming = + ( LCD_VERTTIMING_VN2_N(5) + | LCD_VERTTIMING_VN1_N(17) + | LCD_VERTTIMING_VPW_N(1) + | LCD_VERTTIMING_LPP_N(240) ), + .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(1), + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<7) | (1<<6) | (1<<5)), + .mode_backlight = 6 }, - { /* 1: Pb1100 LCDC 640x480 TFT panel */ - 640, /* xres */ - 480, /* yres */ - 16, /* bpp */ - - "Generic_640x480_16", - - /* mode_control */ - 0x004806a | LCD_DEFAULT_PIX_FORMAT, - - /* mode_horztiming */ - 0x3434d67f, - - /* mode_verttiming */ - 0x0e0e39df, - - /* mode_clkcontrol */ - ( 0 - /*LCD_CLKCONTROL_IB*/ - /*LCD_CLKCONTROL_IC*/ - /*LCD_CLKCONTROL_IH*/ - /*LCD_CLKCONTROL_IV*/ - | LCD_CLKCONTROL_PCD_N(1) ), - - /* mode_pwmdiv */ - 0, - - /* mode_pwmhi */ - 0, - - /* mode_toyclksrc */ - ((1<<7) | (1<<6) | (0<<5)), - - /* mode_backlight */ - 7 + { /* Hitachi SP14Q005 (and possibly others) */ + .xres = 320, + .yres = 240, + .bpp = 4, + .panel_name = "Hitachi_SP14Qxxx", + .mode_control = + ( LCD_CONTROL_C + | LCD_DEFAULT_PIX_FORMAT + | LCD_CONTROL_BPP_4 ), + .mode_horztiming = + ( LCD_HORZTIMING_HN2_N(1) + | LCD_HORZTIMING_HN1_N(1) + | LCD_HORZTIMING_HPW_N(1) + | LCD_HORZTIMING_PPL_N(320) ), + .mode_verttiming = + ( LCD_VERTTIMING_VN2_N(1) + | LCD_VERTTIMING_VN1_N(1) + | LCD_VERTTIMING_VPW_N(1) + | LCD_VERTTIMING_LPP_N(240) ), + .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(4), + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<27) | (1<<26) | (1<<25) | (1<<7) | (1<<6) | (1<<5)), + .mode_backlight = 6 }, - { /* 2: Pb1100 LCDB 640x480 PrimeView TFT panel */ - 640, /* xres */ - 480, /* yres */ - 16, /* bpp */ - - "PrimeView_640x480_16", - - /* mode_control */ - 0x0004886a | LCD_DEFAULT_PIX_FORMAT, - - /* mode_horztiming */ - 0x0e4bfe7f, - - /* mode_verttiming */ - 0x210805df, - - /* mode_clkcontrol */ - 0x00038001, - - /* mode_pwmdiv */ - 0, - - /* mode_pwmhi */ - 0, - - /* mode_toyclksrc */ - ((1<<7) | (1<<6) | (0<<5)), - - /* mode_backlight */ - 7 + { /* Pb1100 LCDC 640x480 TFT panel */ + .xres = 640, + .yres = 480, + .bpp = 16, + .panel_name = "Generic_640x480_16", + .mode_control = 0x004806a | LCD_DEFAULT_PIX_FORMAT, + .mode_horztiming = 0x3434d67f, + .mode_verttiming = 0x0e0e39df, + .mode_clkcontrol = LCD_CLKCONTROL_PCD_N(1), + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<7) | (1<<6) | (0<<5)), + .mode_backlight = 7 }, - { /* 3: Pb1100 800x600x16bpp NEON CRT */ - 800, /* xres */ - 600, /* yres */ - 16, /* bpp */ - - "NEON_800x600_16", - - /* mode_control */ - 0x0004886A | LCD_DEFAULT_PIX_FORMAT, - - /* mode_horztiming */ - 0x005AFF1F, - - /* mode_verttiming */ - 0x16000E57, - - /* mode_clkcontrol */ - 0x00020000, - - /* mode_pwmdiv */ - 0, - - /* mode_pwmhi */ - 0, - - /* mode_toyclksrc */ - ((1<<7) | (1<<6) | (0<<5)), - - /* mode_backlight */ - 7 + { /* Pb1100 LCDB 640x480 PrimeView TFT panel */ + .xres = 640, + .yres = 480, + .bpp = 16, + .panel_name = "PrimeView_640x480_16", + .mode_control = 0x0004886a | LCD_DEFAULT_PIX_FORMAT, + .mode_horztiming = 0x0e4bfe7f, + .mode_verttiming = 0x210805df, + .mode_clkcontrol = 0x00038001, + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<7) | (1<<6) | (0<<5)), + .mode_backlight = 7 }, - { /* 4: Pb1100 640x480x16bpp NEON CRT */ - 640, /* xres */ - 480, /* yres */ - 16, /* bpp */ - - "NEON_640x480_16", - - /* mode_control */ - 0x0004886A | LCD_DEFAULT_PIX_FORMAT, - - /* mode_horztiming */ - 0x0052E27F, - - /* mode_verttiming */ - 0x18000DDF, - - /* mode_clkcontrol */ - 0x00020000, - - /* mode_pwmdiv */ - 0, - - /* mode_pwmhi */ - 0, - - /* mode_toyclksrc */ - ((1<<7) | (1<<6) | (0<<5)), + { /* Pb1100 800x600x16bpp NEON CRT */ + .xres = 800, + .yres = 600, + .bpp = 16, + .panel_name = "NEON_800x600_16", + .mode_control = 0x0004886A | LCD_DEFAULT_PIX_FORMAT, + .mode_horztiming = 0x005AFF1F, + .mode_verttiming = 0x16000E57, + .mode_clkcontrol = 0x00020000, + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<7) | (1<<6) | (0<<5)), + .mode_backlight = 7 + }, - /* mode_backlight */ - 7 + { /* Pb1100 640x480x16bpp NEON CRT */ + .xres = 640, + .yres = 480, + .bpp = 16, + .panel_name = "NEON_640x480_16", + .mode_control = 0x0004886A | LCD_DEFAULT_PIX_FORMAT, + .mode_horztiming = 0x0052E27F, + .mode_verttiming = 0x18000DDF, + .mode_clkcontrol = 0x00020000, + .mode_pwmdiv = 0, + .mode_pwmhi = 0, + .mode_toyclksrc = + ((1<<7) | (1<<6) | (0<<5)), + .mode_backlight = 7 }, + + { /* Prime View PD104SL5 + 800x600 16BPP color LCD */ + .xres = 800, + .yres = 640, + .bpp = 16, + .panel_name = "PrimeView_PD104SL5", + .mode_control = + ( LCD_CONTROL_SBPPF_565 + | LCD_CONTROL_C + | LCD_CONTROL_SM_0 + | LCD_DEFAULT_PIX_FORMAT + | LCD_CONTROL_CCO + | LCD_CONTROL_PT + | LCD_CONTROL_PC + | LCD_CONTROL_BPP_16 ), + .mode_horztiming = + ( LCD_HORZTIMING_HN2_N(30) + | LCD_HORZTIMING_HN1_N(30) + | LCD_HORZTIMING_HPW_N(60) + | LCD_HORZTIMING_PPL_N(800) ), + .mode_verttiming = + ( LCD_VERTTIMING_VN2_N(1) + | LCD_VERTTIMING_VN1_N(1) + | LCD_VERTTIMING_VPW_N(2) + | LCD_VERTTIMING_LPP_N(600) ), + .mode_clkcontrol = + ( LCD_CLKCONTROL_IH + | LCD_CLKCONTROL_IV + | LCD_CLKCONTROL_PCD_N(1)), + .mode_toyclksrc = ((1<<27) | (0<<26) | (1<<25) | (1<<7) | (1<<6) | (0<<5)), + .mode_backlight = 7 + } }; #endif /* _AU1100LCD_H */ From bbreuer@righthandtech.com Tue Feb 15 23:26:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 23:26:49 +0000 (GMT) Received: from mail2.dataflo.net ([IPv6:::ffff:207.252.248.127]:59663 "EHLO mail2.dataflo.net") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 15 Feb 2005 23:26:34 +0000 Received: (qmail 94660 invoked by uid 1009); 15 Feb 2005 17:26:32 -0600 Received: from elk-righthand-router.dataflo.net (HELO server1.RightHand.righthandtech.com) (207.252.249.22) by mail2.dataflo.net with SMTP; 15 Feb 2005 17:26:32 -0600 Subject: swapon failure with au1550 Date: Tue, 15 Feb 2005 17:09:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-ID: X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: swapon failure with au1550 Thread-Index: AcUTs12VqmcQod0AS8mZtpfv1+CwWw== From: "Bob Breuer" 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: 7259 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: bbreuer@righthandtech.com Precedence: bulk X-list: linux-mips With the current cvs on an au1550 configured with 64-bit physical address, I get a kernel oops when trying to activate a swap partition with swapon. It looks like mm/swapfile.c line 1385 is hitting the BUG_ON() in both pte_to_swp_entry() and swp_entry_to_pte(). Bob Breuer From tom@voda.cz Tue Feb 15 23:48:44 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Feb 2005 23:49:00 +0000 (GMT) Received: from gw.voda.cz ([IPv6:::ffff:212.24.154.90]:13485 "EHLO smtp.voda.cz") by linux-mips.org with ESMTP id ; Tue, 15 Feb 2005 23:48:44 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.voda.cz (Postfix) with ESMTP id 5C68311890 for ; Wed, 16 Feb 2005 00:48:38 +0100 (CET) Received: from smtp.voda.cz ([127.0.0.1]) by localhost (gw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16776-09 for ; Wed, 16 Feb 2005 00:48:32 +0100 (CET) Received: from [10.1.1.77] (unknown [213.151.77.162]) by smtp.voda.cz (Postfix) with ESMTP id 375DCFC65 for ; Wed, 16 Feb 2005 00:48:32 +0100 (CET) Message-ID: <42128A4F.20107@voda.cz> Date: Wed, 16 Feb 2005 00:48:31 +0100 From: =?ISO-8859-2?Q?Tom_Vr=E1na?= Organization: VODA IT consulting User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: module segfault problem ADM5120 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at voda.cz 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: 7260 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: tom@voda.cz Precedence: bulk X-list: linux-mips Hello, I am currently experiencing trouble trying to load the madwifi drivers on my MIPS (ADM5120), everytime I end up with the Oops pasted below. Does that provide anyone a clue what may be wrong ? I've tried changing the modules around, but this is what I get... Thanks, Tom Unable to handle kernel paging request at virtual address 00000000, epc == 800fb6fc, ra == 80013fa8 Oops in fault.c:do_page_fault, line 205: $0 : 00000000 10008400 1003a050 fffffff2 00000000 1003a000 0000000a 7fff5bb0 $8 : ffffffff 80a46000 80014180 00000010 00000034 00000000 00000100 00000018 $16: c0000edc 00000050 1003a050 1003a000 7fff5bb0 000003b0 00000000 c0000000 $24: 00000000 004884f0 80184000 80185ec8 100059cc 80013fa8 Hi : 00000000 Lo : 00000001 epc : 800fb6fc Not tainted <4>Status: 10008403 <4>Cause : 10800008 Status: 10008403 <4>Cause : 10800008 Cause : 10800008 Process insmod (pid: 33, stackpage=80184000) Stack: 100059cc 800307f4 801ef440 00000000 ffffffea c0000000 80a46000 1003a000 <4> 00000400 00000004 7fff5bb0 00000001 8001431c 8002382c 00000000 802592e0 <4> 00013a00 00000000 1003a000 00000004 1001fc00 1001efe0 00000001 00000000 <4> 7fff5bb0 80008ec4 10005a0c 100059dc 100059ec 10005ffc 7fff5bb0 00000000 <4> 00000000 10018a04 0000105b 00000400 1001fc00 00000004 1003a000 00000400 <4> 00000021 ... <4>Call Trace:Call Trace: [<800307f4>] [] [<8001431c>] [<8002382c>] [<80008ec4>] Warning (Oops_read): Code line not seen, dumping what data is available >>RA; 80013fa8 >>$1; 10008400 <_binary_ramdisk_gz_size+ff579b6/7ff515b6> >>$2; 1003a050 <_binary_ramdisk_gz_size+ff89606/7ff515b6> >>$5; 1003a000 <_binary_ramdisk_gz_size+ff895b6/7ff515b6> >>$7; 7fff5bb0 <_binary_ramdisk_gz_size+7ff45166/7ff515b6> >>$10; 80014180 >>$18; 1003a050 <_binary_ramdisk_gz_size+ff89606/7ff515b6> >>$19; 1003a000 <_binary_ramdisk_gz_size+ff895b6/7ff515b6> >>$20; 7fff5bb0 <_binary_ramdisk_gz_size+7ff45166/7ff515b6> >>$25; 004884f0 <_binary_ramdisk_gz_size+3d7aa6/7ff515b6> >>$28; 80184000 <_binary_ramdisk_gz_start+45000/b0a4a> >>$29; 80185ec8 <_binary_ramdisk_gz_start+46ec8/b0a4a> >>$30; 100059cc <_binary_ramdisk_gz_size+ff54f82/7ff515b6> >>$31; 80013fa8 >>PC; 800fb6fc <===== -- Tomas Vrana -------------------------- VODA IT consulting, Borkovany 48, 691 75 http://www.voda.cz/ phone: +420 519 419 416 mobile: +420 603 469 305 UIN: 105142752 From pe1rxq@amsat.org Wed Feb 16 00:20:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 00:20:35 +0000 (GMT) Received: from amsfep18-int.chello.nl ([IPv6:::ffff:213.46.243.13]:59229 "EHLO amsfep18-int.chello.nl") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 00:20:21 +0000 Received: from [127.0.0.1] (really [62.195.248.222]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050216002014.JMNU4045.amsfep18-int.chello.nl@[127.0.0.1]>; Wed, 16 Feb 2005 01:20:14 +0100 Message-ID: <421291E2.8020308@amsat.org> Date: Wed, 16 Feb 2005 01:20:50 +0100 From: Jeroen Vreeken User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-2?Q?Tom_Vr=E1na?= CC: linux-mips@linux-mips.org Subject: Re: module segfault problem ADM5120 References: <42128A4F.20107@voda.cz> In-Reply-To: <42128A4F.20107@voda.cz> Content-Type: text/plain; charset=ISO-8859-2; 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: 7261 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: pe1rxq@amsat.org Precedence: bulk X-list: linux-mips Tom Vrána wrote: > Hello, > > I am currently experiencing trouble trying to load the madwifi drivers > on my MIPS (ADM5120), everytime I end up with the Oops pasted below. > Does that provide anyone a clue what may be wrong ? I've tried > changing the modules around, but this is what I get... > > Thanks, Tom > > Unable to handle kernel paging request at virtual address 00000000, > epc == 800fb6fc, ra == Something seems to be trying to access memory location 00000000. Maybe there is some NULL check missing in the driver init code? Jeroen From fcn@noon.org Wed Feb 16 01:55:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 01:56:10 +0000 (GMT) Received: from noon.org ([IPv6:::ffff:192.220.74.114]:36874 "EHLO noon.org") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 01:55:54 +0000 Received: (qmail 4582 invoked by uid 19058); 16 Feb 2005 01:55:51 -0000 Received: from unknown (HELO SJC-FNOON2) ([192.220.74.114]) (envelope-sender ) by 192.220.74.114 (qmail-ldap-1.03) with SMTP for ; 16 Feb 2005 01:55:51 -0000 To: Subject: kernel for custom MV64341 board? X-Attribution: Fredrik X-URL: X-Request-PGP: http://noon.org/keys/pgpkey.txt From: Fredrik Date: Tue, 15 Feb 2005 17:55:50 -0800 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.2 (windows-nt) 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: 7262 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: fcn-sub@noon.org Precedence: bulk X-list: linux-mips Howdy, I'm getting a custom board going: it sports an RM7000 and Marvell MV64341 system controller (alas, no external UART!). I've hacked U-Boot to the point where I can TFTP a kernel image and (start to) boot it. So far I've been using an old 2.4 kernel I used for some Ocelot-G work, just to get past the TFTP-load stage. MY QUESTION IS: What would be the best kernel version for me to now start customizing for my board? Is 2.6 too bleeding-edge, 2.4 too moldy, or what? Dealing with the MV64341 will be most of the effort, of course. The Ocelot boards seem well supported, but there looks to be a lot of code that would have to change (different system controller, different memory map--though I'm flexible--a lot of assumptions about the goodies available on-board, etc.). This is the first time I'll be porting the kernel, so it might be more productive for me to start from a minimalist configuration and add-in what I need. Enough code to set up the memory configuration would be a big help. Suggestions? /Fredrik +----------------------------------------------------------------+ | Fredrik Noon, Senior Software Engineer | | Hifn, Inc. www.hifn.com | | fnoon@hifn.com +1 408 399 3630 | |-------------------+--------------------------------------------| | pgp key: 7840AC55 | +----------------------------------------------------------------+ From Brad_Larson@pmc-sierra.com Wed Feb 16 05:05:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 05:05:51 +0000 (GMT) Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:62203 "HELO mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Wed, 16 Feb 2005 05:05:35 +0000 Received: (qmail 6952 invoked by uid 101); 16 Feb 2005 05:05:27 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 16 Feb 2005 05:05:27 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id j1G55LAt027566; Tue, 15 Feb 2005 21:05:22 -0800 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Tue, 15 Feb 2005 21:05:21 -0800 Message-ID: <04781D450CFF604A9628C8107A62FCCF013DDCA0@sjc1exm01.pmc_nt.nt.pmc-sierra.bc.ca> From: Brad Larson To: "'Fredrik'" , linux-mips@linux-mips.org Subject: RE: kernel for custom MV64341 board? Date: Tue, 15 Feb 2005 21:05:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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: 7263 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_Larson@pmc-sierra.com Precedence: bulk X-list: linux-mips Fredrik, MontaVista completed a 2.4 port to Ocelot-III with RM7900 (or RM7000C) and Discovery-3 (MV64440). Ocelot-III is ATX form factor while previous Ocelot, Ocelot-C and Ocelot-G were CPCI. This is probably close to the board you are describing. Any board dependent changes should have been committed to linux-mips.org by now. --Brad -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Fredrik Sent: Tuesday, February 15, 2005 5:56 PM To: linux-mips@linux-mips.org Subject: kernel for custom MV64341 board? Howdy, I'm getting a custom board going: it sports an RM7000 and Marvell MV64341 system controller (alas, no external UART!). I've hacked U-Boot to the point where I can TFTP a kernel image and (start to) boot it. So far I've been using an old 2.4 kernel I used for some Ocelot-G work, just to get past the TFTP-load stage. MY QUESTION IS: What would be the best kernel version for me to now start customizing for my board? Is 2.6 too bleeding-edge, 2.4 too moldy, or what? Dealing with the MV64341 will be most of the effort, of course. The Ocelot boards seem well supported, but there looks to be a lot of code that would have to change (different system controller, different memory map--though I'm flexible--a lot of assumptions about the goodies available on-board, etc.). This is the first time I'll be porting the kernel, so it might be more productive for me to start from a minimalist configuration and add-in what I need. Enough code to set up the memory configuration would be a big help. Suggestions? /Fredrik +----------------------------------------------------------------+ | Fredrik Noon, Senior Software Engineer | | Hifn, Inc. www.hifn.com | | fnoon@hifn.com +1 408 399 3630 | |-------------------+--------------------------------------------| | pgp key: 7840AC55 | +----------------------------------------------------------------+ From m_lachwani@yahoo.com Wed Feb 16 06:37:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 06:37:55 +0000 (GMT) Received: from web52808.mail.yahoo.com ([IPv6:::ffff:206.190.39.172]:25729 "HELO web52808.mail.yahoo.com") by linux-mips.org with SMTP id ; Wed, 16 Feb 2005 06:37:38 +0000 Received: (qmail 65072 invoked by uid 60001); 16 Feb 2005 06:37:31 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=oF9vC2NkrPnaVSBxw1RyAg1RXa3aTDjUvK5RiX8Z2/roT4KEltxvRQZKv2J7jRonm3nTx1fNNPzQzEbgJoJlYKMUDd6ehYC4eSYTAseoE/49JMVk/Moy3ZR4oQbfM4ywoq98FNuLIE0yoKrvIdu4+WMUYlMu8YO1Ijqq0bitjWQ= ; Message-ID: <20050216063731.65070.qmail@web52808.mail.yahoo.com> Received: from [172.194.5.211] by web52808.mail.yahoo.com via HTTP; Tue, 15 Feb 2005 22:37:31 PST Date: Tue, 15 Feb 2005 22:37:31 -0800 (PST) From: Manish Lachwani Subject: RE: kernel for custom MV64341 board? To: Brad Larson , 'Fredrik' , linux-mips@linux-mips.org In-Reply-To: <04781D450CFF604A9628C8107A62FCCF013DDCA0@sjc1exm01.pmc_nt.nt.pmc-sierra.bc.ca> 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: 7264 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: m_lachwani@yahoo.com Precedence: bulk X-list: linux-mips Brad, Just to let you know, Ocelot III is also fully supported in 2.6. MontaVista has a 2.6 port this board as well. Thanks Manish Lachwani --- Brad Larson wrote: > Fredrik, > > MontaVista completed a 2.4 port to Ocelot-III with > RM7900 (or RM7000C) and Discovery-3 (MV64440). > Ocelot-III is ATX form factor while previous Ocelot, > Ocelot-C and Ocelot-G were CPCI. This is probably > close to the board you are describing. Any board > dependent changes should have been committed to > linux-mips.org by now. > > --Brad > > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf > Of Fredrik > Sent: Tuesday, February 15, 2005 5:56 PM > To: linux-mips@linux-mips.org > Subject: kernel for custom MV64341 board? > > > Howdy, > > I'm getting a custom board going: it sports an > RM7000 and Marvell > MV64341 system controller (alas, no external UART!). > I've hacked > U-Boot to the point where I can TFTP a kernel image > and (start to) > boot it. > > So far I've been using an old 2.4 kernel I used for > some Ocelot-G > work, just to get past the TFTP-load stage. MY > QUESTION IS: What would > be the best kernel version for me to now start > customizing for my > board? Is 2.6 too bleeding-edge, 2.4 too moldy, or > what? Dealing > with the MV64341 will be most of the effort, of > course. > > The Ocelot boards seem well supported, but there > looks to be a lot of > code that would have to change (different system > controller, different > memory map--though I'm flexible--a lot of > assumptions about the > goodies available on-board, etc.). This is the > first time I'll be > porting the kernel, so it might be more productive > for me to start > from a minimalist configuration and add-in what I > need. Enough code > to set up the memory configuration would be a big > help. > > Suggestions? > > /Fredrik > > +----------------------------------------------------------------+ > | Fredrik Noon, Senior Software > Engineer | > | Hifn, Inc. www.hifn.com > | > | fnoon@hifn.com +1 408 399 3630 > | > |-------------------+--------------------------------------------| > | pgp key: > 7840AC55 | > +----------------------------------------------------------------+ > > > From atworther@musicmass.com Wed Feb 16 08:06:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 08:07:12 +0000 (GMT) Received: from p3EE2BCE7.dip.t-dialin.net ([IPv6:::ffff:62.226.188.231]:39837 "EHLO p3EE2BCE7.dip.t-dialin.net") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 08:06:56 +0000 Received: from [IPv6:::ffff:222.64.189.210] ([IPv6:::ffff:222.64.189.210]:40201 "HELO musicmass.com") by linux-mips.net with SMTP id ; Wed, 16 Feb 2005 09:06:56 +0100 Message-ID: <3730F2BA.45D910B@musicmass.com> Date: Wed, 16 Feb 2005 10:51:49 +0500 Reply-To: "ethan upton" From: "ethan upton" User-Agent: AOL 8.0 for Windows US sub 230 X-Accept-Language: en-us MIME-Version: 1.0 To: "Mariano Robert" Subject: time to get a new alternative 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: 7265 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: atworther@musicmass.com Precedence: bulk X-list: linux-mips Realize how one discount pharmacy can save you more? There are over 600 meds for pain relief, sexual health, men's health, anxiety relief, sleeping disorder, anti-depression and more others. Professional consultation and e-script at 0 charge provided when placing order. We have fast delivery provided as well. How can people save on meds while the prices at the local pharmacy are so high. Try internet discount pharmacy, you will see how people save on meds. At the start just want to give internet pharmacy a try. The result is really better than I have expected. Just great. --Online Rx Refill PRO http://dxvs.5eT.moresweety.com/axt/ "do me a favorand check the news online. save pictures articles and videos if you can. i'll stay in contact. to read it, oblivious to everything else, including his wife, Melida, who is in another room "Our family is in need," she writes on her computer."Medical costs cropsickness3dry-ki 9 faunas decalescent brine gauge From thomas.petazzoni@enix.org Wed Feb 16 08:57:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 08:57:54 +0000 (GMT) Received: from the-doors.enix.org ([IPv6:::ffff:62.210.169.120]:20427 "EHLO the-doors.enix.org") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 08:57:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by the-doors.enix.org (Postfix) with ESMTP id 52FEE40120 for ; Wed, 16 Feb 2005 09:59:57 +0100 (CET) Message-ID: <42130B15.8090200@enix.org> Date: Wed, 16 Feb 2005 09:57:57 +0100 From: Thomas Petazzoni User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: kernel for custom MV64341 board? References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E3135A61EDEE04550ED72D3" 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: 7266 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: thomas.petazzoni@enix.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E3135A61EDEE04550ED72D3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Fredrik a =E9crit : > So far I've been using an old 2.4 kernel I used for some Ocelot-G > work, just to get past the TFTP-load stage. MY QUESTION IS: What would > be the best kernel version for me to now start customizing for my > board? Is 2.6 too bleeding-edge, 2.4 too moldy, or what? Dealing > with the MV64341 will be most of the effort, of course. I have recently hacked a 2.6 Linux-MIPS kernel for a custom RM9000 /=20 MV64340 board, and it worked pretty well. For the MV64340 UART, you can find a driver in the Bitkeeper PowerPC=20 tree available at Montavista. Otherwise, I have written an other driver, = much smaller, but maybe less functionnal than the one available from=20 Montavista. > The Ocelot boards seem well supported, but there looks to be a lot of > code that would have to change (different system controller, different > memory map--though I'm flexible--a lot of assumptions about the > goodies available on-board, etc.). This is the first time I'll be > porting the kernel, so it might be more productive for me to start > from a minimalist configuration and add-in what I need. Enough code > to set up the memory configuration would be a big help. Have a look at Linux-MIPS Wiki (http://www.linux-mips.org) it contains=20 an updated version of the MIPS porting guide from Jun Sun. It's a very=20 good starting point in my opinion. Thomas --=20 PETAZZONI Thomas - thomas.petazzoni@enix.org http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk http://kos.enix.org, http://sos.enix.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 --------------enig9E3135A61EDEE04550ED72D3 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 iD8DBQFCEwsY9lPLMJjT96cRAlPWAJ4tgC+SrNpWJXiafG5UuyC5a7YDOwCfVwuo +1H9n4YGTGDMMFfefGDS8y8= =O7OY -----END PGP SIGNATURE----- --------------enig9E3135A61EDEE04550ED72D3-- From geert@linux-m68k.org Wed Feb 16 09:23:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 09:23:52 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:26249 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 09:23:37 +0000 Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j1G9NZGU019364; Wed, 16 Feb 2005 10:23:35 +0100 (MET) Date: Wed, 16 Feb 2005 10:23:33 +0100 (CET) From: Geert Uytterhoeven To: Ulrich Eckhardt cc: Linux/MIPS Development , Ralf Baechle Subject: Re: [patch] generic framebuffer support, cleanups and buglets with BPP < 32 In-Reply-To: <200502151439.06976.eckhardt@satorlaser.com> Message-ID: References: <200502151439.06976.eckhardt@satorlaser.com> 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: 7267 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Tue, 15 Feb 2005, Ulrich Eckhardt wrote: > Changes: > * removed trailing whitespace > * use helper function for common bitwise operations > * fixed several cases where either the wrong mask was used for bitops > or the mask was computed falsely, messing up <32 BPP support > * added self-tests for bitcpy_rev() algorithm in module-init function > * no need to use explicitly sized integers in some cases > * added a few comments where things weren't obvious to me I forwarded your mail to linux-fbdev-devel. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From fcn@noon.org Wed Feb 16 19:40:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Feb 2005 19:41:13 +0000 (GMT) Received: from noon.org ([IPv6:::ffff:192.220.74.114]:50188 "EHLO noon.org") by linux-mips.org with ESMTP id ; Wed, 16 Feb 2005 19:40:57 +0000 Received: (qmail 8329 invoked by uid 19058); 16 Feb 2005 19:40:52 -0000 Received: from unknown (HELO SJC-FNOON2) ([192.220.74.114]) (envelope-sender ) by 192.220.74.114 (qmail-ldap-1.03) with SMTP for ; 16 Feb 2005 19:40:52 -0000 To: linux-mips@linux-mips.org Subject: Re: kernel for custom MV64341 board? X-Attribution: Fredrik X-URL: X-Request-PGP: http://noon.org/keys/pgpkey.txt References: <20050216063731.65070.qmail@web52808.mail.yahoo.com> From: Fredrik Date: Wed, 16 Feb 2005 11:40:50 -0800 In-Reply-To: <20050216063731.65070.qmail@web52808.mail.yahoo.com> (Manish Lachwani's message of "Tue, 15 Feb 2005 22:37:31 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.2 (windows-nt) 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: 7268 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: fcn-sub@noon.org Precedence: bulk X-list: linux-mips Thank you all for the feedback. It sounds like 2.6 is a safe starting point: now I just have to learn how paging tables get set up. :o /Fredrik +----------------------------------------------------------------+ | Fredrik Noon, Senior Software Engineer | | Hifn, Inc. www.hifn.com | | fnoon@hifn.com +1 408 399 3630 | |-------------------+--------------------------------------------| | pgp key: 7840AC55 | +----------------------------------------------------------------+ From Rishabh@soc-soft.com Thu Feb 17 05:08:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 05:09:06 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:1797 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 05:08:50 +0000 Received: from mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Thu, 17 Feb 2005 10:40:22 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C514AE.FB88C691" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: HIGHMEM Query Date: Thu, 17 Feb 2005 10:40:22 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C53FAF5@soc-mail.soc-soft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: HIGHMEM Query Thread-Index: AcUUrvrEzJ/OWOMRTyGz66/gZQHugg== From: To: Cc: , , 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: 7269 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C514AE.FB88C691 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C514AE.FB88C691" ------_=_NextPart_002_01C514AE.FB88C691 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi, =0D I have been working on HIGHMEM fixation for 2.4.20 linux MVL kernel for MIPS architecture.=0D I am getting DATA BUS ERROR(ADDR: 0xffffd000) exception when loading (copying the data received from ethernet to the kernel space in FIXADDR SPACE) "/sbin/init" from TARGET ROOT DIR (through NFS). I figured out that this is because there is no corresponding page table entry for the same.=0D =0D I checked that the virtual address is generated by making a call to kmap_atomic(). Which internally calls set_pte() and then local_flush_tlb_all(). Virtual Address is generated by making a call to =0D vaddr =3D __fix_to_virt(FIX_KMAP_BEGIN + idx); 1> Where is the page table entries updated? 2> When are they updated with the processor? =0D =0D Regards, =0D Rishabh =0D =0D 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_002_01C514AE.FB88C691 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

hi,

 

I have been working on HIGHMEM fixation for 2.4.20 linux MVL kernel for MIPS architecture.=

I am getting DATA BUS ERROR(ADDR: 0xffffd000) exception when loading (copying the data received from ethernet to the kernel space in FIXADDR SPACE)= “/sbin/init” from TARGET ROOT DIR (through NFS).= I figured out that this is because there is no corresponding page table entry for the same.

 

I checked that the virtual address is generated by= making a call to kmap_atomic(). Which internally calls set_pte() and then local_flush_tlb_all(). Virtual Address is generated= by making a call to        =

 

vaddr =3D= __fix_to_virt(FIX_KMAP_BEGIN + idx);

1> Where is the page table entries= updated?

2> When are they updated with the= processor?

 

 

Regards,

 

Rishabh

 

         =             &nb= sp;            =   

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_002_01C514AE.FB88C691-- ------_=_NextPart_001_01C514AE.FB88C691 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhQAJaAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== ------_=_NextPart_001_01C514AE.FB88C691-- From thomas.petazzoni@enix.org Thu Feb 17 09:24:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 09:24:53 +0000 (GMT) Received: from postfix3-1.free.fr ([IPv6:::ffff:213.228.0.44]:5851 "EHLO postfix3-1.free.fr") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 09:24:37 +0000 Received: from [192.168.1.2] (humanoidz.org [81.56.146.155]) by postfix3-1.free.fr (Postfix) with ESMTP id 8ED181734D2 for ; Thu, 17 Feb 2005 10:24:32 +0100 (CET) Message-ID: <421462CF.3070900@enix.org> Date: Thu, 17 Feb 2005 10:24:31 +0100 From: Thomas Petazzoni User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: kernel for custom MV64341 board? References: <20050216063731.65070.qmail@web52808.mail.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA154CF3BAC29393AACA0E7F8" 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: 7270 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: thomas.petazzoni@enix.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA154CF3BAC29393AACA0E7F8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Fredrik a =E9crit : > Thank you all for the feedback. It sounds like 2.6 is a safe starting > point: now I just have to learn how paging tables get set up. :o You don't have to worry about paging tables. Support for TLB on R7000 is = already included in Linux-MIPS, you don't have to do anything about it.=20 (At least for the port I did on a RM9000-based platform, I didn't had to = worry about it). Read the MIPS porting guide available on the Wiki :=20 http://www.linux-mips.org/wiki/index.php/Porting, it's really really usef= ul. Thomas --=20 PETAZZONI Thomas - thomas.petazzoni@enix.org http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk KOS: http://kos.enix.org/ - SOS: http://sos.enix.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 --------------enigA154CF3BAC29393AACA0E7F8 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.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFGLP9lPLMJjT96cRAvDgAJ45ZZpIs3RWku9h59MohZ+3dMbC9ACffzCB HQBCI+gBP4gY/9H52r5PmQE= =Poq0 -----END PGP SIGNATURE----- --------------enigA154CF3BAC29393AACA0E7F8-- From TheNop@gmx.net Thu Feb 17 10:02:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 10:02:34 +0000 (GMT) Received: from mail.gmx.de ([IPv6:::ffff:213.165.64.20]:3807 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Thu, 17 Feb 2005 10:02:19 +0000 Received: (qmail invoked by alias); 17 Feb 2005 10:02:12 -0000 Received: from c209082.adsl.hansenet.de (EHLO [192.168.0.1]) (213.39.209.82) by mail.gmx.net (mp002) with SMTP; 17 Feb 2005 11:02:12 +0100 X-Authenticated: #947741 Message-ID: <42146C27.8080404@gmx.net> Date: Thu, 17 Feb 2005 11:04:23 +0100 From: TheNop User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: configuration of yosemite board with titan 1.2 Content-Type: text/plain; charset=us-ascii; 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: 7271 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: TheNop@gmx.net Precedence: bulk X-list: linux-mips Hello, today i got the yosemite board with titan 1.2. Currently I have problems to get the kernel 2.6.10.rc1 running (it runs on the old yosemite quite well). The first thing I noticed is that after starting the kernel no output on the console is printed. On the new yosemite board I got, the external UART chip (U36) is not mounted anymore. Could that cause my problems? Is there anybody how can send my a .config file to get the yosemite working? Best regards TheNop From ibrahim@schenk.isar.de Thu Feb 17 12:08:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 12:08:44 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:2628 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 12:08:29 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1HC87H14390; Thu, 17 Feb 2005 13:08:07 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1HC87c18392; Thu, 17 Feb 2005 13:08:07 +0100 Message-ID: <42148926.8040306@schenk.isar.de> Date: Thu, 17 Feb 2005 13:08:06 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TheNop CC: linux-mips@linux-mips.org Subject: Re: configuration of yosemite board with titan 1.2 References: <42146C27.8080404@gmx.net> In-Reply-To: <42146C27.8080404@gmx.net> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7272 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Hi, if you want to use the internal UART, you need an adapted kernel from PMC. The kernel from linux-mips.org only supports the external UART chip. You can download an adapted source archive from the PMC-Sierra ftp site. Rojhalat Ibrahim TheNop wrote: > Hello, > > today i got the yosemite board with titan 1.2. > Currently I have problems to get the kernel 2.6.10.rc1 running (it runs > on the old yosemite quite well). > The first thing I noticed is that after starting the kernel no output on > the console is printed. > On the new yosemite board I got, the external UART chip (U36) is not > mounted anymore. Could that cause my problems? > > Is there anybody how can send my a .config file to get the yosemite > working? > > Best regards > TheNop > > From TheNop@gmx.net Thu Feb 17 12:40:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 12:40:44 +0000 (GMT) Received: from pop.gmx.net ([IPv6:::ffff:213.165.64.20]:28311 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Thu, 17 Feb 2005 12:40:29 +0000 Received: (qmail invoked by alias); 17 Feb 2005 12:40:23 -0000 Received: from c209082.adsl.hansenet.de (EHLO [192.168.0.1]) (213.39.209.82) by mail.gmx.net (mp022) with SMTP; 17 Feb 2005 13:40:23 +0100 X-Authenticated: #947741 Message-ID: <4214913A.7000601@gmx.net> Date: Thu, 17 Feb 2005 13:42:34 +0100 From: TheNop User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: configuration of yosemite board with titan 1.2 References: <42146C27.8080404@gmx.net> <42148926.8040306@schenk.isar.de> In-Reply-To: <42148926.8040306@schenk.isar.de> Content-Type: text/plain; charset=us-ascii; 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: 7273 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: TheNop@gmx.net Precedence: bulk X-list: linux-mips Hi, on the ftp site of PMC I only found kernel 2.4.26 sources supporting internal UART. I need kernel 2.6. Is it planed to integrate internal UART support to linux-mips.org 2.6 sources? Why PMC-Sierra removed the external UART chip? So it is not possible to use current yosemite boards with linux-mips.org :-( Beste regards TheNop Rojhalat Ibrahim wrote: > Hi, > > if you want to use the internal UART, you need an adapted > kernel from PMC. The kernel from linux-mips.org only supports > the external UART chip. You can download an adapted source > archive from the PMC-Sierra ftp site. > > Rojhalat Ibrahim > > > TheNop wrote: > >> Hello, >> >> today i got the yosemite board with titan 1.2. >> Currently I have problems to get the kernel 2.6.10.rc1 running (it >> runs on the old yosemite quite well). >> The first thing I noticed is that after starting the kernel no output >> on the console is printed. >> On the new yosemite board I got, the external UART chip (U36) is not >> mounted anymore. Could that cause my problems? >> >> Is there anybody how can send my a .config file to get the yosemite >> working? >> >> Best regards >> TheNop >> >> > > > From ibrahim@schenk.isar.de Thu Feb 17 16:00:22 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 16:00:36 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:44868 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 16:00:22 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1HG0BH16048; Thu, 17 Feb 2005 17:00:11 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1HG0Ac20287; Thu, 17 Feb 2005 17:00:10 +0100 Message-ID: <4214BF8A.5090206@schenk.isar.de> Date: Thu, 17 Feb 2005 17:00:10 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TheNop CC: linux-mips@linux-mips.org Subject: Re: configuration of yosemite board with titan 1.2 References: <42146C27.8080404@gmx.net> <42148926.8040306@schenk.isar.de> <4214913A.7000601@gmx.net> In-Reply-To: <4214913A.7000601@gmx.net> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7274 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips TheNop wrote: > Hi, > > on the ftp site of PMC I only found kernel 2.4.26 sources supporting > internal UART. > I need kernel 2.6. They have recently (about one week ago) uploaded a kernel 2.6 that supports the internal UART. > Is it planed to integrate internal UART support to linux-mips.org 2.6 > sources? > > Why PMC-Sierra removed the external UART chip? > So it is not possible to use current yosemite boards with linux-mips.org > :-( > Not without the external UART chip. On my board with chip revision 1.2 the external UART chip is still present. I just had to change some resistor stuffing option to make it work. From TheNop@gmx.net Thu Feb 17 16:15:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 16:15:15 +0000 (GMT) Received: from pop.gmx.net ([IPv6:::ffff:213.165.64.20]:34496 "HELO mail.gmx.net") by linux-mips.org with SMTP id ; Thu, 17 Feb 2005 16:15:00 +0000 Received: (qmail invoked by alias); 17 Feb 2005 16:14:54 -0000 Received: from c209082.adsl.hansenet.de (EHLO [192.168.0.1]) (213.39.209.82) by mail.gmx.net (mp008) with SMTP; 17 Feb 2005 17:14:54 +0100 X-Authenticated: #947741 Message-ID: <4214C381.8070107@gmx.net> Date: Thu, 17 Feb 2005 17:17:05 +0100 From: TheNop User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: configuration of yosemite board with titan 1.2 References: <42146C27.8080404@gmx.net> <42148926.8040306@schenk.isar.de> <4214913A.7000601@gmx.net> <4214BF8A.5090206@schenk.isar.de> In-Reply-To: <4214BF8A.5090206@schenk.isar.de> 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: 7275 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: TheNop@gmx.net Precedence: bulk X-list: linux-mips Hi, thanx, now I found the 2.6 sources with internal UART support. I was probably blind. :-) Best regards Rojhalat Ibrahim wrote: > TheNop wrote: > >> Hi, >> >> on the ftp site of PMC I only found kernel 2.4.26 sources supporting >> internal UART. >> I need kernel 2.6. > > > They have recently (about one week ago) uploaded a kernel 2.6 > that supports the internal UART. > > >> Is it planed to integrate internal UART support to linux-mips.org 2.6 >> sources? >> >> Why PMC-Sierra removed the external UART chip? >> So it is not possible to use current yosemite boards with >> linux-mips.org :-( >> > > Not without the external UART chip. On my board with chip revision 1.2 > the external UART chip is still present. I just had to change some > resistor stuffing option to make it work. > > > From ralf@linux-mips.org Thu Feb 17 20:18:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 20:19:04 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:23681 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 20:18:48 +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 j1HKCddV009597; Thu, 17 Feb 2005 20:12:39 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1H1Y7hW015558; Thu, 17 Feb 2005 01:34:07 GMT Date: Thu, 17 Feb 2005 01:34:06 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Atsushi Nemoto , macro@mips.com, Richard Sandiford , linux-mips@linux-mips.org Subject: Re: [PATCH] I/O helpers rework Message-ID: <20050217013406.GA14909@linux-mips.org> References: <87k6qh2e6j.fsf@redhat.com> <20050122.015040.108744446.anemo@mba.ocn.ne.jp> 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: 7276 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 Sat, Jan 22, 2005 at 02:51:47AM +0000, Maciej W. Rozycki wrote: > > 1. How about using 'const void *' for outs*()/reads*() ? This will > > remove some compiler warnings too. Also, it seems 'volatile' for > > memory buffer are unneeded. > > > > 2. In *in*()/*out*(), it would be better to call __swizzle_addr*() > > AFTER adding mips_io_port_base. This unifies the meaning of the > > argument of __swizzle_addr*() (always virtual address). Then, > > mach-specific __swizzle_addr*() can to every evil thing based on > > the argument. > > > > 3. How about Moving generic ioswab*() to mangle-port.h ? Also how > > about passing virtual address to *ioswab*() ? Then we can provide > > mach-specific ioswab*() and can do every evil thing based on its > > argument. It is usefull on machines which have regions with > > different endian conversion scheme. > > Thanks for your insight -- your comments are not lost and I am working on > taking them into account. But meanwhile a confusion around the semantics > of these operations arose (there is no documentation on them and some > drivers expect some of these functions to swap, while others expect them > not to) and changes were made to the tree that invalidated some of the > fixes. That needs to be addressed first and I expect another update to > the file. Here's a patch I'm going to start with. Functions it adds have > been named dma_* to indicate they are meant to preserve memory byte > ordering. Looks good but I don't really like the dma_* name prefix as these functions really have nothing to do with DMA - in fact they're the opposite. Ralf From ralf@linux-mips.org Thu Feb 17 20:43:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 20:43:19 +0000 (GMT) Received: from alg138.algor.co.uk ([IPv6:::ffff:62.254.210.138]:48769 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 20:43: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 j1HKauoP010335; Thu, 17 Feb 2005 20:36:56 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1HKasGd010334; Thu, 17 Feb 2005 20:36:54 GMT Date: Thu, 17 Feb 2005 20:36:54 +0000 From: Ralf Baechle To: Rishabh@soc-soft.com Cc: linux-mips@linux-mips.org, mel@skynet.ie, jbglaw@lug-owl.de Subject: Re: HIGHMEM Query Message-ID: <20050217203654.GA9671@linux-mips.org> References: <4BF47D56A0DD2346A1B8D622C5C5902C53FAF5@soc-mail.soc-soft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C53FAF5@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: 7277 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, Feb 17, 2005 at 10:40:22AM +0530, Rishabh@soc-soft.com wrote: First, fix your mailer setup, it's littering emails with extra carriage returns. > I have been working on HIGHMEM fixation for 2.4.20 linux MVL kernel for > MIPS architecture. > I am getting DATA BUS ERROR(ADDR: 0xffffd000) exception when loading > (copying the data received from ethernet to the kernel space in FIXADDR > SPACE) "/sbin/init" from TARGET ROOT DIR (through NFS). I figured out > that this is because there is no corresponding page table entry for the > same. That does not make sense. If you don't have a pagetable entry the CPU will take a TLB reload exception. If the entry is invalid, the kernel will die with an oops. A bus error has different causes. Ralf From vprashant@echelon.com Thu Feb 17 23:56:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Feb 2005 23:56:49 +0000 (GMT) Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:64964 "EHLO [205.229.50.10]") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 23:56:33 +0000 Received: from miles.echelon.com by [205.229.50.10] via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Thu, 17 Feb 2005 15:56:33 -0800 Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19) id <19FLM0PK>; Thu, 17 Feb 2005 15:56:30 -0800 Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB59016544F9@miles.echelon.com> From: Prashant Viswanathan To: "'linux-mips@linux-mips.org'" Subject: dbAu1550: booting linux from flash Date: Thu, 17 Feb 2005 15:56:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: 7278 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: vprashant@echelon.com Precedence: bulk X-list: linux-mips Hi All, I have a dbAu1550 board running Linux. The way it works now, I have YAMON booting the kernel via tftp. The kernel itself mounts the root file system from NAND flash (JFFS2). How can I use YAMON to copy the kernel image to flash (so that I don't have to tftp every time)? And what changes would I have to make to the way I build the "falsh-resident-kernel" (if any)? Thank you in advance, Prashant From ppopov@embeddedalley.com Fri Feb 18 00:10:10 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Feb 2005 00:10:25 +0000 (GMT) Received: from mail.chipsandsystems.com ([IPv6:::ffff:64.164.196.27]:60802 "EHLO mail.chipsag.com") by linux-mips.org with ESMTP id ; Fri, 18 Feb 2005 00:10:10 +0000 Received: from [10.1.100.35] ([10.1.100.35]) by mail.chipsag.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Feb 2005 16:13:05 -0800 Message-ID: <4215325D.5050709@embeddedalley.com> Date: Thu, 17 Feb 2005 16:10:05 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prashant Viswanathan CC: "'linux-mips@linux-mips.org'" Subject: Re: dbAu1550: booting linux from flash References: <5375D9FB1CC3994D9DCBC47C344EEB59016544F9@miles.echelon.com> In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB59016544F9@miles.echelon.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2005 00:13:05.0119 (UTC) FILETIME=[9DEE26F0:01C5154E] 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: 7279 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 Prashant Viswanathan wrote: > Hi All, > > I have a dbAu1550 board running Linux. The way it works now, I have YAMON > booting the kernel via tftp. The kernel itself mounts the root file system > from NAND flash (JFFS2). > > How can I use YAMON to copy the kernel image to flash (so that I don't have > to tftp every time)? And what changes would I have to make to the way I > build the "falsh-resident-kernel" (if any)? You can put the kernel in NOR flash, but I don't think yamon supports the nand part on the board. Putting the kernel in NOR flash is easy, especially if you use the zImage support. You can then use yamon to just jump to that flash location and the kernel will relocate itself from flash to RAM, decompress itself, and boot. Pete From hjl@lucon.org Fri Feb 18 06:44:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Feb 2005 06:44:51 +0000 (GMT) Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:25027 "EHLO sccrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Fri, 18 Feb 2005 06:44:32 +0000 Received: from lucon.org ([24.6.212.230]) by comcast.net (sccrmhc12) with ESMTP id <2005021806442401200rtaobe>; Fri, 18 Feb 2005 06:44:25 +0000 Received: by lucon.org (Postfix, from userid 1000) id 43BC765604; Thu, 17 Feb 2005 22:44:24 -0800 (PST) Date: Thu, 17 Feb 2005 22:44:24 -0800 From: "H. J. Lu" To: linux-gcc@vger.kernel.org Cc: gcc@gcc.gnu.org, GNU C Library , Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , Linas Vepstas Subject: The Linux binutils 2.15.94.0.2.2 is released Message-ID: <20050218064424.GA16817@lucon.org> 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: 7280 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: hjl@lucon.org Precedence: bulk X-list: linux-mips This is the beta release of binutils 2.15.94.0.2.2 for Linux, which is based on binutils 2004 1220 in CVS on sources.redhat.com plus various changes. It is purely for Linux. Please report any bugs related to binutils 2.15.94.0.2.2 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.15.94.0.2: 1. Fix greater than 64K section support in linker. 2. Properly handle i386 and x86_64 protected symbols in linker. 3. Fix readelf for LEB128 on 64bit hosts. 4. Speed up readelf for section group process. 5. Include ia64 texinfo pages. 6. Change ia64 assembler to check hint.b for Montecito. 7. Improve relaxation failure report in ia64 linker. 8. Fix ia64 linker to allow relax backward branch in the same section. Changes from binutils 2.15.94.0.1: 1. Update from binutils 2004 1220. 2. Fix strip for TLS symbol references. Changes from binutils 2.15.92.0.2: 1. Update from binutils 2004 1121. 2. Put ia64 .ctors/.dtors sections next to small data section for Intel ia64 compiler. 3. Fix -Bdynamic/-Bstatic handling for linker script. 4. Provide more information on relocation overflow. 5. Add --sort-section to linker. 6. Support icc 8.1 unwind info in readelf. 7. Fix the infinite loop bug on bad input in the ia64 assembler. 8. Fix ia64 SECREL relocation in linker. 9. Fix a section group memory leak in readelf. Changes from binutils 2.15.91.0.2: 1. Update from binutils 2004 0927. 2. Work around a section header bug in Intel ia64 compiler. 3. Fix an unwind directive bug in the ia64 assembler. 4. Fix various PPC bugs. 5. Update ARM support. 6. Fix an x86-64 linker warning while building Linux kernel. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with linkonce section. 5. Added --add-needed/--no-add-needed options to linker. 6. Fix the SHF_LINK_ORDER support. 7. Fix the ia64 assembler for multiple sections with the same name and SHT_IA_64_UNWIND sections. 8. Fix the ia64 assembler for merge section and relaxation. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Prescott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.15.94.0.2.2.tar.bz2. Source code. 2. binutils-2.15.94.0.2-2.15.94.0.2.2.diff.bz2. Patch against the previous beta source code. 3. binutils-2.15.94.0.2.2-1.i386.rpm. IA-32 binary RPM for RedHat EL 3. 4. binutils-2.15.94.0.2.2-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3. 5. binutils-2.15.94.0.2.2-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3. There is no separate source rpm. You can do # rpmbuild -ta binutils-2.15.94.0.2.2.tar.bz2 to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 02/18/2005 From macro@linux-mips.org Fri Feb 18 19:44:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Feb 2005 19:44:24 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:49937 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 18 Feb 2005 19:44:06 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D5189E1CAF; Fri, 18 Feb 2005 20:43:58 +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 06829-01; Fri, 18 Feb 2005 20:43:58 +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 2A46EE1CA8; Fri, 18 Feb 2005 20:43:58 +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 j1IJhwxO028226; Fri, 18 Feb 2005 20:44:01 +0100 Date: Fri, 18 Feb 2005 19:44:08 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: Atsushi Nemoto , macro@mips.com, Richard Sandiford , linux-mips@linux-mips.org Subject: Re: [PATCH] I/O helpers rework In-Reply-To: <20050217013406.GA14909@linux-mips.org> Message-ID: References: <87k6qh2e6j.fsf@redhat.com> <20050122.015040.108744446.anemo@mba.ocn.ne.jp> <20050217013406.GA14909@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: 7281 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 On Thu, 17 Feb 2005, Ralf Baechle wrote: > > Thanks for your insight -- your comments are not lost and I am working on > > taking them into account. But meanwhile a confusion around the semantics > > of these operations arose (there is no documentation on them and some > > drivers expect some of these functions to swap, while others expect them > > not to) and changes were made to the tree that invalidated some of the > > fixes. That needs to be addressed first and I expect another update to > > the file. Here's a patch I'm going to start with. Functions it adds have > > been named dma_* to indicate they are meant to preserve memory byte > > ordering. > > Looks good but I don't really like the dma_* name prefix as these functions > really have nothing to do with DMA - in fact they're the opposite. Well, the name is meant to imply DMA byte ordering is preserved. If that's not clear enough (I don't insist it is), then I'd love to hear a reasonable proposal for an alternative. Maciej From goldfinger@member.fsf.org Sat Feb 19 19:42:36 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Feb 2005 19:42:51 +0000 (GMT) Received: from host101-161.pool80181.interbusiness.it ([IPv6:::ffff:80.181.161.101]:22266 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Sat, 19 Feb 2005 19:42:36 +0000 Received: by localhost.localdomain (Postfix, from userid 501) id 83C2710F0A9; Sat, 19 Feb 2005 21:41:31 +0100 (CET) Subject: Origin-2000 networking problem ! From: Michele Carla` To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 19 Feb 2005 21:41:31 +0100 Message-Id: <1108845691.3061.15.camel@trogo> 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: 7282 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 Hello... I have some problem with an Origin-2000 I have succesfully booted a kernel trhough tftp. After this, the kernel mount correctly the root file system, that is located on a scsi drive (it is a debian-sargge). ...everithing seams to be correct, but networking doesn't want to work. I have configured eth0 trough ifconfig (setting MAC handly, if not it is setted to 00:00:00:00...), but if I try to ping another computer, any packet is sent, and the packet counter (ifconfig) doesn't progress. Also the interrupt counter (/dev/interrupt) doesn't progress. this is the log of the boot: http://www.hackbloc.net/~goldfinger/boot any idea ??? Thanks for any help... sorry for my English... Michele Carla` goldfinger@member.fsf.org From pdh@colonel-panic.org Sun Feb 20 14:54:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 14:54:49 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:14209 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 14:54:31 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2sTb-0006vf-00; Sun, 20 Feb 2005 14:54:27 +0000 Date: Sun, 20 Feb 2005 14:54:27 +0000 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2.6] Cobalt fixes [1 of 6] Message-ID: <20050220145427.GA26582@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: 7283 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 Patch to add 2.6.x support for MIPs based Qubes/RaQs. P. --- linux-cvs/arch/mips/Makefile 2005-01-30 03:55:14.000000000 +0000 +++ linux-wip/arch/mips/Makefile 2005-02-20 13:48:22.000000000 +0000 @@ -324,6 +324,7 @@ load-$(CONFIG_MIPS_XXS1500) += 0xfffffff # Cobalt Server # core-$(CONFIG_MIPS_COBALT) += arch/mips/cobalt/ +cflags-$(CONFIG_MIPS_COBALT) += -Iinclude/asm-mips/cobalt load-$(CONFIG_MIPS_COBALT) += 0xffffffff80080000 # --- linux-cvs/include/asm-mips/cobalt/cobalt.h 2003-11-13 16:56:16.000000000 +0000 +++ linux-wip/include/asm-mips/cobalt/cobalt.h 2005-02-20 13:48:22.000000000 +0000 @@ -19,7 +19,10 @@ * 9 - PCI * 14 - IDE0 * 15 - IDE1 - * + */ +#define COBALT_QUBE_SLOT_IRQ 9 + +/* * CPU IRQs are 16 ... 23 */ #define COBALT_TIMER_IRQ 18 @@ -30,7 +33,6 @@ #define COBALT_SERIAL_IRQ 21 #define COBALT_SCSI_IRQ 21 #define COBALT_VIA_IRQ 22 /* Chained to VIA ISA bridge */ -#define COBALT_QUBE_SLOT_IRQ 23 /* * PCI configuration space manifest constants. These are wired into @@ -69,13 +71,16 @@ * Most of this really should go into a separate GT64111 header file. */ #define GT64111_IO_BASE 0x10000000UL +#define GT64111_IO_END 0x11ffffffUL +#define GT64111_MEM_BASE 0x12000000UL +#define GT64111_MEM_END 0x13ffffffUL #define GT64111_BASE 0x14000000UL -#define GALILEO_REG(ofs) (KSEG0 + GT64111_BASE + (unsigned long)(ofs)) +#define GALILEO_REG(ofs) CKSEG1ADDR(GT64111_BASE + (unsigned long)(ofs)) #define GALILEO_INL(port) (*(volatile unsigned int *) GALILEO_REG(port)) #define GALILEO_OUTL(val, port) \ do { \ - *(volatile unsigned int *) GALILEO_REG(port) = (port); \ + *(volatile unsigned int *) GALILEO_REG(port) = (val); \ } while (0) #define GALILEO_T0EXP 0x0100 @@ -86,5 +91,21 @@ do { \ GALILEO_OUTL((0x80000000 | (PCI_SLOT (devfn) << 11) | \ (PCI_FUNC (devfn) << 8) | (where)), GT_PCI0_CFGADDR_OFS) +#define COBALT_LED_PORT (*(volatile unsigned char *) CKSEG1ADDR(0x1c000000)) +# define COBALT_LED_BAR_LEFT (1 << 0) /* Qube */ +# define COBALT_LED_BAR_RIGHT (1 << 1) /* Qube */ +# define COBALT_LED_WEB (1 << 2) /* RaQ */ +# define COBALT_LED_POWER_OFF (1 << 3) /* RaQ */ +# define COBALT_LED_RESET 0x0f + +#define COBALT_KEY_PORT ((~*(volatile unsigned int *) CKSEG1ADDR(0x1d000000) >> 24) & COBALT_KEY_MASK) +# define COBALT_KEY_CLEAR (1 << 1) +# define COBALT_KEY_LEFT (1 << 2) +# define COBALT_KEY_UP (1 << 3) +# define COBALT_KEY_DOWN (1 << 4) +# define COBALT_KEY_RIGHT (1 << 5) +# define COBALT_KEY_ENTER (1 << 6) +# define COBALT_KEY_SELECT (1 << 7) +# define COBALT_KEY_MASK 0xfe #endif /* __ASM_COBALT_H */ --- linux-cvs/arch/mips/cobalt/reset.c 2002-12-02 00:27:43.000000000 +0000 +++ linux-wip/arch/mips/cobalt/reset.c 2005-02-20 13:48:22.000000000 +0000 @@ -16,48 +16,45 @@ #include #include #include +#include -void cobalt_machine_restart(char *command) +void cobalt_machine_halt(void) { - *(volatile char *)0xbc000000 = 0x0f; + int state, last, diff; + unsigned long mark; /* - * Ouch, we're still alive ... This time we take the silver bullet ... - * ... and find that we leave the hardware in a state in which the - * kernel in the flush locks up somewhen during of after the PCI - * detection stuff. + * turn off bar on Qube, flash power off LED on RaQ (0.5Hz) + * + * restart if ENTER and SELECT are pressed */ - set_c0_status(ST0_BEV | ST0_ERL); - change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); - flush_cache_all(); - write_c0_wired(0); - __asm__ __volatile__( - "jr\t%0" - : - : "r" (0xbfc00000)); -} -extern int led_state; -#define kLED 0xBC000000 -#define LEDSet(x) (*(volatile unsigned char *) kLED) = (( unsigned char)x) + last = COBALT_KEY_PORT; -void cobalt_machine_halt(void) -{ - int mark; + for (state = 0;;) { + + state ^= COBALT_LED_POWER_OFF; + COBALT_LED_PORT = state; + + diff = COBALT_KEY_PORT ^ last; + last ^= diff; - /* Blink our cute? little LED (number 3)... */ - while (1) { - led_state = led_state | ( 1 << 3 ); - LEDSet(led_state); - mark = jiffies; - while (jiffies<(mark+HZ)); - led_state = led_state & ~( 1 << 3 ); - LEDSet(led_state); - mark = jiffies; - while (jiffies<(mark+HZ)); + if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT))) + COBALT_LED_PORT = COBALT_LED_RESET; + + for (mark = jiffies; jiffies - mark < HZ;) + ; } } +void cobalt_machine_restart(char *command) +{ + COBALT_LED_PORT = COBALT_LED_RESET; + + /* we should never get here */ + cobalt_machine_halt(); +} + /* * This triggers the luser mode device driver for the power switch ;-) */ --- linux-cvs/arch/mips/cobalt/setup.c 2004-08-26 21:18:00.000000000 +0100 +++ linux-wip/arch/mips/cobalt/setup.c 2005-02-20 13:48:22.000000000 +0000 @@ -30,27 +30,25 @@ extern void cobalt_machine_power_off(voi int cobalt_board_id; -static char my_cmdline[CL_SIZE] = { - "console=ttyS0,115200 " -#ifdef CONFIG_IP_PNP - "ip=on " -#endif -#ifdef CONFIG_ROOT_NFS - "root=/dev/nfs " -#else - "root=/dev/hda1 " -#endif - }; - const char *get_system_type(void) { + switch (cobalt_board_id) { + case COBALT_BRD_ID_QUBE1: + return "Cobalt Qube"; + case COBALT_BRD_ID_RAQ1: + return "Cobalt RaQ"; + case COBALT_BRD_ID_QUBE2: + return "Cobalt Qube2"; + case COBALT_BRD_ID_RAQ2: + return "Cobalt RaQ2"; + } return "MIPS Cobalt"; } static void __init cobalt_timer_setup(struct irqaction *irq) { - /* Load timer value for 150 Hz */ - GALILEO_OUTL(500000, GT_TC0_OFS); + /* Load timer value for 1KHz */ + GALILEO_OUTL(50*1000*1000 / 1000, GT_TC0_OFS); /* Register our timer interrupt */ setup_irq(COBALT_TIMER_IRQ, irq); @@ -58,17 +56,17 @@ static void __init cobalt_timer_setup(st /* Enable timer ints */ GALILEO_OUTL((GALILEO_ENTC0 | GALILEO_SELTC0), GT_TC_CONTROL_OFS); /* Unmask timer int */ - GALILEO_OUTL(0x100, GT_INTRMASK_OFS); + GALILEO_OUTL(GALILEO_T0EXP, GT_INTRMASK_OFS); } extern struct pci_ops gt64111_pci_ops; static struct resource cobalt_mem_resource = { - "GT64111 PCI MEM", GT64111_IO_BASE, 0xffffffffUL, IORESOURCE_MEM + "GT64111 PCI MEM", GT64111_MEM_BASE, GT64111_MEM_END, IORESOURCE_MEM }; static struct resource cobalt_io_resource = { - "GT64111 IO MEM", 0x00001000UL, 0x0fffffffUL, IORESOURCE_IO + "GT64111 IO MEM", 0x00001000UL, GT64111_IO_END - GT64111_IO_BASE, IORESOURCE_IO }; static struct resource cobalt_io_resources[] = { @@ -86,10 +84,10 @@ static struct pci_controller cobalt_pci_ .mem_resource = &cobalt_mem_resource, .mem_offset = 0, .io_resource = &cobalt_io_resource, - .io_offset = 0x00001000UL - GT64111_IO_BASE + .io_offset = 0 - GT64111_IO_BASE }; -static void __init cobalt_setup(void) +static int __init cobalt_setup(void) { unsigned int devfn = PCI_DEVFN(COBALT_PCICONF_VIA, 0); int i; @@ -100,7 +98,10 @@ static void __init cobalt_setup(void) board_timer_setup = cobalt_timer_setup; - set_io_port_base(KSEG1ADDR(GT64111_IO_BASE)); + set_io_port_base(CKSEG1ADDR(GT64111_IO_BASE)); + + /* IO region should cover all Galileo IO */ + ioport_resource.end = 0x0fffffff; /* * This is a prom style console. We just poke at the @@ -120,27 +121,50 @@ static void __init cobalt_setup(void) cobalt_board_id >>= ((VIA_COBALT_BRD_ID_REG & 3) * 8); cobalt_board_id = VIA_COBALT_BRD_REG_to_ID(cobalt_board_id); + printk("Cobalt board ID: %d\n", cobalt_board_id); + #ifdef CONFIG_PCI register_pci_controller(&cobalt_pci_controller); #endif + + return 0; } early_initcall(cobalt_setup); /* * Prom init. We read our one and only communication with the firmware. - * Grab the amount of installed memory + * Grab the amount of installed memory. + * Better boot loaders (CoLo) pass a command line too :-) */ void __init prom_init(void) { - int argc = fw_arg0; - - strcpy(arcs_cmdline, my_cmdline); + int narg, indx, posn, nchr; + unsigned long memsz; + char **argv; mips_machgroup = MACH_GROUP_COBALT; - add_memory_region(0x0, argc & 0x7fffffff, BOOT_MEM_RAM); + memsz = fw_arg0 & 0x7fff0000; + narg = fw_arg0 & 0x0000ffff; + + if (narg) { + arcs_cmdline[0] = '\0'; + argv = (char **) fw_arg1; + posn = 0; + for (indx = 1; indx < narg; ++indx) { + nchr = strlen(argv[indx]); + if (posn + 1 + nchr + 1 > sizeof(arcs_cmdline)) + break; + if (posn) + arcs_cmdline[posn++] = ' '; + strcpy(arcs_cmdline + posn, argv[indx]); + posn += nchr; + } + } + + add_memory_region(0x0, memsz, BOOT_MEM_RAM); } unsigned long __init prom_free_prom_memory(void) From pdh@colonel-panic.org Sun Feb 20 14:56:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 14:57:11 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:15489 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 14:56:56 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2sVy-0006w4-00; Sun, 20 Feb 2005 14:56:54 +0000 Date: Sun, 20 Feb 2005 14:56:53 +0000 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2.6] Cobalts fixes [2 of 6] Message-ID: <20050220145653.GB26582@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: 7284 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 Fix Qube/RaQ PCI support under 2.6. P. --- linux-cvs/arch/mips/pci/fixup-cobalt.c 2004-10-31 16:07:33.000000000 +0000 +++ linux-wip/arch/mips/pci/fixup-cobalt.c 2005-02-20 14:10:39.000000000 +0000 @@ -47,6 +47,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V static void qube_raq_galileo_fixup(struct pci_dev *dev) { unsigned short galileo_id; + int i; /* Fix PCI latency-timer and cache-line-size values in Galileo * host bridge. @@ -55,6 +56,13 @@ static void qube_raq_galileo_fixup(struc pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, 7); /* + * The code described by the comment below has been removed + * as it causes bus mastering by the Ethernet controllers + * to break under any kind of network load. We always set + * the retry timeouts to their maximum. + * + * --x--x--x--x--x--x--x--x--x--x--x--x--x--x--x--x--x--x--x--x-- + * * On all machines prior to Q2, we had the STOP line disconnected * from Galileo to VIA on PCI. The new Galileo does not function * correctly unless we have it connected. @@ -64,19 +72,34 @@ 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); + +#if 0 if (galileo_id >= 0x10) { /* New Galileo, assumes PCI stop line to VIA is connected. */ GALILEO_OUTL(0x4020, GT_PCI0_TOR_OFS); - } else if (galileo_id == 0x1 || galileo_id == 0x2) { + } else if (galileo_id == 0x1 || galileo_id == 0x2) +#endif + { signed int timeo; /* XXX WE MUST DO THIS ELSE GALILEO LOCKS UP! -DaveM */ timeo = GALILEO_INL(GT_PCI0_TOR_OFS); /* 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_GALILEO, PCI_ANY_ID, +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL, PCI_ANY_ID, qube_raq_galileo_fixup); static char irq_tab_cobalt[] __initdata = { --- linux-cvs/include/asm-mips/cobalt/mach-gt64120.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-wip/include/asm-mips/cobalt/mach-gt64120.h 2005-02-20 13:48:22.000000000 +0000 @@ -0,0 +1 @@ +/* there's something here ... in the dark */ From pdh@colonel-panic.org Sun Feb 20 14:57:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 14:58:04 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:15745 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 14:57:48 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2sWo-0006wK-00 for ; Sun, 20 Feb 2005 14:57:46 +0000 Date: Sun, 20 Feb 2005 14:57:46 +0000 To: linux-mips@linux-mips.org Subject: [PATCH 2.6] Cobalt fixes [3 of 6] Message-ID: <20050220145746.GC26582@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: 7285 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 Fix Cobalt LCD driver for 2.6. P. --- linux-cvs/drivers/char/lcd.c 2005-01-25 04:28:12.000000000 +0000 +++ linux-wip/drivers/char/lcd.c 2005-02-20 13:48:22.000000000 +0000 @@ -575,8 +575,8 @@ static inline int button_pressed(void) static int lcd_waiters = 0; -static long lcd_read(struct inode *inode, struct file *file, char *buf, - unsigned long count) +static ssize_t lcd_read(struct file *file, char *buf, + size_t count, loff_t *ofs) { long buttons_now; --- linux-cvs/drivers/char/lcd.h 2005-01-13 14:05:52.000000000 +0000 +++ linux-wip/drivers/char/lcd.h 2005-02-20 13:48:22.000000000 +0000 @@ -22,7 +22,7 @@ static int timeout(volatile unsigned lon #define MAX_IDLE_TIME 120 struct lcd_display { - unsigned long buttons; + unsigned buttons; int size1; int size2; unsigned char line1[LCD_CHARS_PER_LINE]; From pdh@colonel-panic.org Sun Feb 20 14:59:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 15:00:14 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:16257 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 14:59:59 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2sYv-0006wr-00; Sun, 20 Feb 2005 14:59:57 +0000 Date: Sun, 20 Feb 2005 14:59:57 +0000 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2.6] Cobalt fixes [4 of 6] Message-ID: <20050220145957.GE26582@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: 7286 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 Tulip fixes for Qube/RaQ in 2.6 P. --- linux-cvs/drivers/net/tulip/eeprom.c 2004-12-04 18:16:05.000000000 +0000 +++ linux-wip/drivers/net/tulip/eeprom.c 2005-02-20 13:48:22.000000000 +0000 @@ -63,6 +63,22 @@ static struct eeprom_fixup eeprom_fixups */ { 0x1e00, 0x0000, 0x000b, 0x8f01, 0x0103, 0x0300, 0x0821, 0x000, 0x0001, 0x0000, 0x01e1 } }, + {"Cobalt Microserver", 0, 0x10, 0xE0, {0x1e00, /* 0 == controller #, 1e == offset */ + 0x0000, /* 0 == high offset, 0 == gap */ + 0x0800, /* Default Autoselect */ + 0x8001, /* 1 leaf, extended type, bogus len */ + 0x0003, /* Type 3 (MII), PHY #0 */ + 0x0400, /* 0 init instr, 4 reset instr */ + 0x0801, /* Set control mode, GP0 output */ + 0x0000, /* Drive GP0 Low (RST is active low) */ + 0x0800, /* control mode, GP0 input (undriven) */ + 0x0000, /* clear control mode */ + 0x7800, /* 100TX FDX + HDX, 10bT FDX + HDX */ + 0x01e0, /* Advertise all above */ + 0x5000, /* FDX all above */ + 0x1800, /* Set fast TTM in 100bt modes */ + 0x0000, /* PHY cannot be unplugged */ + }}, {NULL}}; --- linux-cvs/drivers/net/tulip/media.c 2005-01-13 14:06:15.000000000 +0000 +++ linux-wip/drivers/net/tulip/media.c 2005-02-20 13:48:22.000000000 +0000 @@ -399,6 +399,9 @@ void tulip_select_media(struct net_devic } tp->csr6 = new_csr6 | (tp->csr6 & 0xfdff) | (tp->full_duplex ? 0x0200 : 0); + + udelay(1000); + return; } --- linux-cvs/drivers/net/tulip/tulip_core.c 2005-01-25 04:28:36.000000000 +0000 +++ linux-wip/drivers/net/tulip/tulip_core.c 2005-02-20 13:48:22.000000000 +0000 @@ -1511,8 +1511,8 @@ static int __devinit tulip_init_one (str (PCI_SLOT(pdev->devfn) == 12))) { /* Cobalt MAC address in first EEPROM locations. */ sa_offset = 0; - /* No media table either */ - tp->flags &= ~HAS_MEDIA_TABLE; + /* Ensure our media table fixup get's applied */ + memcpy(ee_data + 16, ee_data, 8); } #endif #ifdef CONFIG_GSC From pdh@colonel-panic.org Sun Feb 20 15:01:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 15:01:20 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:16513 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 15:01:05 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2sZz-0006x5-00; Sun, 20 Feb 2005 15:01:03 +0000 Date: Sun, 20 Feb 2005 15:01:03 +0000 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2.6] Cobalt fixes [5 of 6] Message-ID: <20050220150103.GF26582@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: 7287 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 Fix Qube/RaQ PIO IDE to prevent D-cache aliasing problems. P. --- linux-cvs/include/asm-mips/cobalt/ide.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-wip/include/asm-mips/cobalt/ide.h 2005-02-20 14:00:49.000000000 +0000 @@ -0,0 +1,83 @@ + +/* + * PIO "in" transfers can cause D-cache lines to be allocated + * to the data being read. If the target is the page cache then + * the kernel can create a user space mapping of the same page + * without flushing it from the D-cache. This has large potential + * to create cache aliases. The Cobalts seem to trigger this + * problem easily. + * + * MIPs doesn't have a flush_dcache_range() so we roll + * our own. + * + * -- pdh + */ + +#define MAX_HWIFS 2 + +#include + +static inline void __flush_dcache(void) +{ + unsigned long dc_size, dc_line, addr, end; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = CKSEG0; + end = addr + dc_size; + + for (; addr < end; addr += dc_line) + flush_dcache_line_indexed(addr); +} + +static inline void __flush_dcache_range(unsigned long start, unsigned long end) +{ + unsigned long dc_size, dc_line, addr; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = start & ~(dc_line - 1); + end += dc_line - 1; + + if (end - addr < dc_size) + for (; addr < end; addr += dc_line) + flush_dcache_line(addr); + else + __flush_dcache(); +} + +static inline void __ide_insw(unsigned long port, void *addr, unsigned int count) +{ + insw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_insl(unsigned long port, void *addr, unsigned int count) +{ + insl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +static inline void __ide_mm_insw(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_mm_insl(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +#define insw __ide_insw +#define insl __ide_insl + +#define __ide_mm_outsw writesw +#define __ide_mm_outsl writesl From pdh@colonel-panic.org Sun Feb 20 15:01:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 15:02:03 +0000 (GMT) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:17025 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 15:01:41 +0000 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1D2saZ-0006xJ-00 for ; Sun, 20 Feb 2005 15:01:39 +0000 Date: Sun, 20 Feb 2005 15:01:39 +0000 To: linux-mips@linux-mips.org Subject: [PATCH 2.6] Cobalt fixes [6 of 6] Message-ID: <20050220150139.GG26582@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: 7288 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 Fix Qube/RaQ interrupt handling under 2.6. P. --- linux-cvs/arch/mips/cobalt/int-handler.S 2003-11-13 14:30:45.000000000 +0000 +++ linux-wip/arch/mips/cobalt/int-handler.S 2005-02-20 13:48:22.000000000 +0000 @@ -18,8 +18,8 @@ SAVE_ALL CLI - la ra, ret_from_irq - move a1, sp + PTR_LA ra, ret_from_irq + move a0, sp j cobalt_irq END(cobalt_handle_int) --- linux-cvs/arch/mips/cobalt/irq.c 2004-08-20 10:19:01.000000000 +0100 +++ linux-wip/arch/mips/cobalt/irq.c 2005-02-20 13:48:22.000000000 +0000 @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -25,8 +26,8 @@ extern void cobalt_handle_int(void); * the CPU interrupt lines, and ones that come in on the via chip. The CPU * mappings are: * - * 16, - Software interrupt 0 (unused) IE_SW0 - * 17 - Software interrupt 1 (unused) IE_SW0 + * 16 - Software interrupt 0 (unused) IE_SW0 + * 17 - Software interrupt 1 (unused) IE_SW1 * 18 - Galileo chip (timer) IE_IRQ0 * 19 - Tulip 0 + NCR SCSI IE_IRQ1 * 20 - Tulip 1 IE_IRQ2 @@ -82,11 +83,15 @@ asmlinkage void cobalt_irq(struct pt_reg } if (pending & CAUSEF_IP7) { /* int 23 */ - do_IRQ(COBALT_QUBE_SLOT_IRQ, regs); + do_IRQ(23, regs); return; } } +static struct irqaction irq_via = { + no_action, 0, { { 0, } }, "cascade", NULL, NULL +}; + void __init arch_init_irq(void) { set_except_vector(0, cobalt_handle_int); @@ -99,4 +104,6 @@ void __init arch_init_irq(void) * (except IE4, we already masked those at VIA level) */ change_c0_status(ST0_IM, IE_IRQ4); + + setup_irq(COBALT_VIA_IRQ, &irq_via); } From rsandifo@redhat.com Sun Feb 20 20:14:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Feb 2005 20:15:15 +0000 (GMT) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:55988 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Sun, 20 Feb 2005 20:14:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1KKEsGE026892 for ; Sun, 20 Feb 2005 15:14:54 -0500 Received: from firetop.home (vpn50-19.rdu.redhat.com [172.16.50.19]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1KKElK14094 for ; Sun, 20 Feb 2005 15:14:48 -0500 Received: from rsandifo by firetop.home with local (Exim 4.34) id 1D2x4r-0000oL-SM for linux-mips@linux-mips.org; Sun, 20 Feb 2005 21:00:46 +0000 To: linux-mips@linux-mips.org Subject: [PATCH] SMP/TLB problems with 64-bit kernels From: Richard Sandiford Date: Sun, 20 Feb 2005 19:49:13 +0000 Message-ID: <87r7jbdnba.fsf@firetop.home> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: 7289 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: rsandifo@redhat.com Precedence: bulk X-list: linux-mips A 64-bit SB1 SMP kernel built from current 2.6 CVS sources will hang when trying to run init. This is probably the same as the bug reported here: http://www.linux-mips.org/archives/linux-mips/2005-01/msg00086.html The patch below fixes things for me. There were three separate problems: - The CONFIG_BUILD_ELF64 version of get_saved_sp miscalculated kernel_sp: it failed to shift the address left 16 bits after adding in %hi(kernel_sp). - build_get_pmde64 says: /* * 64 bit SMP has the lower part of &pgd_current[smp_processor_id()] * stored in CONTEXT. */ if (in_compat_space_p(pgdc)) { i_dmfc0(p, ptr, C0_CONTEXT); i_dsra(p, ptr, ptr, 23); i_ld(p, ptr, 0, ptr); } else { #ifdef CONFIG_BUILD_ELF64 ... #else ... #endif } but for CONFIG_BUILD_ELF64, the context register contains smp_processor_id(), not &pgd_current[smp_processor_id()]. The patch rearranges the code as follows: #ifdef CONFIG_BUILD_ELF64 ... #else /* * 64 bit SMP has the lower part of &pgd_current[smp_processor_id()] * stored in CONTEXT. */ if (in_compat_space_p(pgdc)) { i_dmfc0(p, ptr, C0_CONTEXT); i_dsra(p, ptr, ptr, 23); i_ld(p, ptr, 0, ptr); } else { ... } #endif - The final "..." above is: i_dmfc0(p, ptr, C0_CONTEXT); i_lui(p, tmp, rel_highest(pgdc)); i_dsll(p, ptr, ptr, 9); i_daddiu(p, tmp, tmp, rel_higher(pgdc)); ---> i_dsrl32(p, ptr, ptr, 0); ---> i_and(p, ptr, ptr, tmp); i_dmfc0(p, tmp, C0_BADVADDR); i_ld(p, ptr, 0, ptr); There are three problems here: * the high 32 bits of the address (tmp) aren't shifted left 32 places. * If you calculate foo as: (%highest(foo) << 48) + (%higher(foo) << 32) + x then "x" is a signed number, so the shift should be dsra32, not dsrl32. This is the only use of dsrl32 in the file, and nothing uses dsra32 at the moment, so the patch replaces the dsrl32 definitions with dsra32 definitions. * The "and" should be a "daddu". (I'm not sure how this case triggers. Won't pgd_current always be in the compat region if !CONFIG_BUILD_ELF64?) Also, whenever the CONFIG_BUILD_ELF64 code reads smp_processor_id() from the context register, it uses the result to index arrays of 8-byte values. We can avoid a shift in both the TLB code and in get_saved_sp if we store smp_processor_id() * 8 in the context register (i.e. if TLBMISS_HANDLER_SETUP shifts the value left by 26 rather than 23). I've tested the patch with both CONFIG_BUILD_ELF64 and !CONFIG_BUILD_ELF64, and in both cases it fixes the hang and seems to give a stable kernel. I also tried a !CONFIG_BUILD_ELF64 with the in_compat_space_p() check above disabled, forcing the longer version to be used. Please apply if OK. Richard Index: arch/mips/mm/tlbex.c =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/tlbex.c,v retrieving revision 1.16 diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.16 tlbex.c --- arch/mips/mm/tlbex.c 12 Jan 2005 16:38:50 -0000 1.16 +++ arch/mips/mm/tlbex.c 20 Feb 2005 18:58:35 -0000 @@ -91,7 +91,7 @@ enum opcode { insn_addu, insn_addiu, insn_and, insn_andi, insn_beq, insn_beql, insn_bgez, insn_bgezl, insn_bltz, insn_bltzl, insn_bne, insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0, - insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32, + insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsra32, insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld, insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0, insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll, @@ -134,7 +134,7 @@ static __initdata struct insn insn_table { insn_dsll32, M(spec_op,0,0,0,0,dsll32_op), RT | RD | RE }, { insn_dsra, M(spec_op,0,0,0,0,dsra_op), RT | RD | RE }, { insn_dsrl, M(spec_op,0,0,0,0,dsrl_op), RT | RD | RE }, - { insn_dsrl32, M(spec_op,0,0,0,0,dsrl32_op), RT | RD | RE }, + { insn_dsra32, M(spec_op,0,0,0,0,dsra32_op), RT | RD | RE }, { insn_dsubu, M(spec_op,0,0,0,0,dsubu_op), RS | RT | RD }, { insn_eret, M(cop0_op,cop_op,0,0,0,eret_op), 0 }, { insn_j, M(j_op,0,0,0,0,0), JIMM }, @@ -366,7 +366,7 @@ I_u2u1u3(_dsll); I_u2u1u3(_dsll32); I_u2u1u3(_dsra); I_u2u1u3(_dsrl); -I_u2u1u3(_dsrl32); +I_u2u1u3(_dsra32); I_u3u1u2(_dsubu); I_0(_eret); I_u1(_j); @@ -942,6 +942,14 @@ build_get_pmde64(u32 **p, struct label * /* No i_nop needed here, since the next insn doesn't touch TMP. */ #ifdef CONFIG_SMP +#ifdef CONFIG_BUILD_ELF64 + i_dmfc0(p, ptr, C0_CONTEXT); + i_dsrl(p, ptr, ptr, 23); + i_LA_mostly(p, tmp, pgdc); + i_daddu(p, ptr, ptr, tmp); + i_dmfc0(p, tmp, C0_BADVADDR); + i_ld(p, ptr, rel_lo(pgdc), ptr); +#else /* * 64 bit SMP has the lower part of &pgd_current[smp_processor_id()] * stored in CONTEXT. @@ -951,25 +959,17 @@ build_get_pmde64(u32 **p, struct label * i_dsra(p, ptr, ptr, 23); i_ld(p, ptr, 0, ptr); } else { -#ifdef CONFIG_BUILD_ELF64 - i_dmfc0(p, ptr, C0_CONTEXT); - i_dsrl(p, ptr, ptr, 23); - i_dsll(p, ptr, ptr, 3); - i_LA_mostly(p, tmp, pgdc); - i_daddu(p, ptr, ptr, tmp); - i_dmfc0(p, tmp, C0_BADVADDR); - i_ld(p, ptr, rel_lo(pgdc), ptr); -#else i_dmfc0(p, ptr, C0_CONTEXT); i_lui(p, tmp, rel_highest(pgdc)); i_dsll(p, ptr, ptr, 9); i_daddiu(p, tmp, tmp, rel_higher(pgdc)); - i_dsrl32(p, ptr, ptr, 0); - i_and(p, ptr, ptr, tmp); + i_dsra32(p, ptr, ptr, 0); + i_dsll32(p, tmp, tmp, 0); + i_daddu(p, ptr, ptr, tmp); i_dmfc0(p, tmp, C0_BADVADDR); i_ld(p, ptr, 0, ptr); -#endif } +#endif #else i_LA_mostly(p, ptr, pgdc); i_ld(p, ptr, rel_lo(pgdc), ptr); Index: include/asm-mips/mmu_context.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/mmu_context.h,v retrieving revision 1.48 diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.48 mmu_context.h --- include/asm-mips/mmu_context.h 8 Jan 2005 15:03:53 -0000 1.48 +++ include/asm-mips/mmu_context.h 20 Feb 2005 18:59:53 -0000 @@ -40,7 +40,7 @@ #define TLBMISS_HANDLER_SETUP() \ #endif #if defined(CONFIG_MIPS64) && defined(CONFIG_BUILD_ELF64) #define TLBMISS_HANDLER_SETUP() \ - write_c0_context((unsigned long) smp_processor_id() << 23); \ + write_c0_context((unsigned long) smp_processor_id() << 26); \ TLBMISS_HANDLER_SETUP_PGD(swapper_pg_dir) #endif Index: include/asm-mips/stackframe.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/stackframe.h,v retrieving revision 1.36 diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.36 stackframe.h --- include/asm-mips/stackframe.h 13 Feb 2005 00:32:43 -0000 1.36 +++ include/asm-mips/stackframe.h 20 Feb 2005 18:59:54 -0000 @@ -76,12 +76,12 @@ #define _ASM_STACKFRAME_H #endif #if defined(CONFIG_MIPS64) && defined(CONFIG_BUILD_ELF64) MFC0 k1, CP0_CONTEXT - dsrl k1, 23 - dsll k1, k1, 3 lui k0, %highest(kernelsp) daddiu k0, %higher(kernelsp) dsll k0, k0, 16 daddiu k0, %hi(kernelsp) + dsrl k1, 23 + dsll k0, k0, 16 daddu k1, k1, k0 LONG_L k1, %lo(kernelsp)(k1) #endif From jgreen@users.sourceforge.net Mon Feb 21 05:00:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 05:00:36 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:30689 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 05:00:16 +0000 Received: from suzaku.infostations.net (suzaku.infostations.net [71.4.40.34]) by mail-relay.infostations.net (Postfix) with ESMTP id 41B619F855 for ; Sun, 20 Feb 2005 21:00:18 -0800 (PST) Received: from host-69-19-145-86.rev.o1.com ([69.19.145.86]) by suzaku.infostations.net with esmtp (Exim 4.41 #1) id 1D35g4-0006JZ-Vz for ; Sun, 20 Feb 2005 21:00:13 -0800 Subject: Fixes to MTD flash driver on AMD Alchemy db1100 board From: Josh Green To: linux-mips@linux-mips.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZJuk6N3uUH2kBZsUDiL1" Date: Sun, 20 Feb 2005 21:01:45 -0800 Message-Id: <1108962105.6611.24.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: 7290 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 --=-ZJuk6N3uUH2kBZsUDiL1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I found a couple compile problems with the drivers/mtd/maps/db1x00-flash.c MTD driver. I'm using linux-mips CVS from a few weeks back, corresponding to 2.6.11rc2. I noticed some recent CVS traffic in regards to this driver, but I didn't see them in cvsweb on the linux-mips site. My apologies if this is something that has already been reported. Fixes in the patch below: - Specify proper paths for #include of au1000.h and db1x00.h - Cast return value of ioremap to (void __iomem *) to get rid of warning concerning conversion of integer to pointer - Setup DB1X00_BOTH_BANKS, DB1X00_BOOT_ONLY, and DB1X00_USER_ONLY defines in db1x00.h (used pb1550.h as an example) since they seemed to be missing which was causing the following to be triggered: #error MTD_DB1X00 define combo error /* should never happen */ I can see the partitions in /dev/mtd now, but I have not thoroughly tested it yet to see if there are any other problems. Best regards, Josh Green --------------- diff -ruN a/drivers/mtd/maps/db1x00-flash.c b/drivers/mtd/maps/db1x00-flash= .c --- a/drivers/mtd/maps/db1x00-flash.c 2005-02-20 20:29:30.268844944 -0800 +++ b/drivers/mtd/maps/db1x00-flash.c 2005-02-20 20:29:36.025969728 -0800 @@ -18,8 +18,8 @@ #include =20 #include -#include -#include +#include +#include =20 #ifdef DEBUG_RW #define DBG(x...) printk(x) @@ -192,7 +192,7 @@ */ printk(KERN_NOTICE "Db1xxx flash: probing %d-bit flash bus\n",=20 db1xxx_mtd_map.bankwidth*8); - db1xxx_mtd_map.virt =3D (unsigned long)ioremap(window_addr, window_size); + db1xxx_mtd_map.virt =3D (void __iomem *)ioremap(window_addr, window_size)= ; db1xxx_mtd =3D do_map_probe("cfi_probe", &db1xxx_mtd_map); if (!db1xxx_mtd) return -ENXIO; db1xxx_mtd->owner =3D THIS_MODULE; diff -ruN a/include/asm-mips/mach-db1x00/db1x00.h b/include/asm-mips/mach-d= b1x00/db1x00.h --- a/include/asm-mips/mach-db1x00/db1x00.h 2005-02-20 20:30:51.710463936 -= 0800 +++ b/include/asm-mips/mach-db1x00/db1x00.h 2005-02-20 20:31:00.671101712 -= 0800 @@ -134,6 +134,14 @@ #define SET_VCC_VPP(VCC, VPP, SLOT)\ ((((VCC)<<2) | ((VPP)<<0)) << ((SLOT)*8)) =20 +#if defined(CONFIG_MTD_DB1X00_BOOT) && defined(CONFIG_MTD_DB1X00_USER) +#define DB1X00_BOTH_BANKS +#elif defined(CONFIG_MTD_DB1X00_BOOT) && !defined(CONFIG_MTD_DB1X00_USER) +#define DB1X00_BOOT_ONLY +#elif !defined(CONFIG_MTD_DB1X00_BOOT) && defined(CONFIG_MTD_DB1X00_USER) +#define DB1X00_USER_ONLY +#endif + /* SD controller macros */ /* * Detect card. --=-ZJuk6N3uUH2kBZsUDiL1 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) iD8DBQBCGWs5RoMuWKCcbgQRAqH7AKCslw5LfIxEI6qngt8X8Sq02kf9ygCgh8ZX ESEzXwIqUy0QwewHPi2eFPI= =wk1p -----END PGP SIGNATURE----- --=-ZJuk6N3uUH2kBZsUDiL1-- From ppopov@embeddedalley.com Mon Feb 21 05:23:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 05:23:54 +0000 (GMT) Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:18081 "HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Mon, 21 Feb 2005 05:23:38 +0000 Received: from unknown (HELO ?10.2.2.62?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp002.bizmail.yahoo.com with SMTP; 21 Feb 2005 05:23:35 -0000 Message-ID: <4219704E.8000207@embeddedalley.com> Date: Sun, 20 Feb 2005 21:23:26 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Green CC: linux-mips@linux-mips.org Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board References: <1108962105.6611.24.camel@SillyPuddy.localdomain> In-Reply-To: <1108962105.6611.24.camel@SillyPuddy.localdomain> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7291 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 Josh Green wrote: > Hello, I found a couple compile problems with the > drivers/mtd/maps/db1x00-flash.c MTD driver. I'm using linux-mips CVS > from a few weeks back, corresponding to 2.6.11rc2. I noticed some > recent CVS traffic in regards to this driver, but I didn't see them in > cvsweb on the linux-mips site. My apologies if this is something that > has already been reported. Fixes in the patch below: > > - Specify proper paths for #include of au1000.h and db1x00.h > - Cast return value of ioremap to (void __iomem *) to get rid of warning > concerning conversion of integer to pointer > - Setup DB1X00_BOTH_BANKS, DB1X00_BOOT_ONLY, and DB1X00_USER_ONLY > defines in db1x00.h (used pb1550.h as an example) since they seemed to > be missing which was causing the following to be triggered: > > #error MTD_DB1X00 define combo error /* should never happen */ > > I can see the partitions in /dev/mtd now, but I have not thoroughly > tested it yet to see if there are any other problems. The latest mtd driver(s) are in the mtd tree and the db1x00 driver there should work. Ralf pulls the mtd code from kernel.org and .. I'm not sure when and how the code gets in kernel.org. The problem is that if I pull from the mtd tree and push the latest drivers in linux-mips, they'll still get overwritten with the code from kernel.org. I'm not sure what's the best way to maintain these drivers and avoid the confusion. Pete > > Best regards, > Josh Green > > > --------------- > > > diff -ruN a/drivers/mtd/maps/db1x00-flash.c b/drivers/mtd/maps/db1x00-flash.c > --- a/drivers/mtd/maps/db1x00-flash.c 2005-02-20 20:29:30.268844944 -0800 > +++ b/drivers/mtd/maps/db1x00-flash.c 2005-02-20 20:29:36.025969728 -0800 > @@ -18,8 +18,8 @@ > #include > > #include > -#include > -#include > +#include > +#include > > #ifdef DEBUG_RW > #define DBG(x...) printk(x) > @@ -192,7 +192,7 @@ > */ > printk(KERN_NOTICE "Db1xxx flash: probing %d-bit flash bus\n", > db1xxx_mtd_map.bankwidth*8); > - db1xxx_mtd_map.virt = (unsigned long)ioremap(window_addr, window_size); > + db1xxx_mtd_map.virt = (void __iomem *)ioremap(window_addr, window_size); > db1xxx_mtd = do_map_probe("cfi_probe", &db1xxx_mtd_map); > if (!db1xxx_mtd) return -ENXIO; > db1xxx_mtd->owner = THIS_MODULE; > diff -ruN a/include/asm-mips/mach-db1x00/db1x00.h b/include/asm-mips/mach-db1x00/db1x00.h > --- a/include/asm-mips/mach-db1x00/db1x00.h 2005-02-20 20:30:51.710463936 -0800 > +++ b/include/asm-mips/mach-db1x00/db1x00.h 2005-02-20 20:31:00.671101712 -0800 > @@ -134,6 +134,14 @@ > #define SET_VCC_VPP(VCC, VPP, SLOT)\ > ((((VCC)<<2) | ((VPP)<<0)) << ((SLOT)*8)) > > +#if defined(CONFIG_MTD_DB1X00_BOOT) && defined(CONFIG_MTD_DB1X00_USER) > +#define DB1X00_BOTH_BANKS > +#elif defined(CONFIG_MTD_DB1X00_BOOT) && !defined(CONFIG_MTD_DB1X00_USER) > +#define DB1X00_BOOT_ONLY > +#elif !defined(CONFIG_MTD_DB1X00_BOOT) && defined(CONFIG_MTD_DB1X00_USER) > +#define DB1X00_USER_ONLY > +#endif > + > /* SD controller macros */ > /* > * Detect card. > > From eckhardt@satorlaser.com Mon Feb 21 10:42:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 10:42:29 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.177]:21228 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 10:42:12 +0000 Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D3B10-00084u-00 for linux-mips@linux-mips.org; Mon, 21 Feb 2005 11:42:10 +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 1D3B10-0001Jx-00 for linux-mips@linux-mips.org; Mon, 21 Feb 2005 11:42:10 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board Date: Mon, 21 Feb 2005 11:44:58 +0100 User-Agent: KMail/1.7.1 References: <1108962105.6611.24.camel@SillyPuddy.localdomain> In-Reply-To: <1108962105.6611.24.camel@SillyPuddy.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502211144.58470.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: 7292 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 Josh Green wrote: > Hello, I found a couple compile problems with the > drivers/mtd/maps/db1x00-flash.c MTD driver. I'm using linux-mips CVS > from a few weeks back, corresponding to 2.6.11rc2. I noticed some > recent CVS traffic in regards to this driver, but I didn't see them in > cvsweb on the linux-mips site. My apologies if this is something that > has already been reported. Even if reported, it hasn't been fixed - I have similar problems. > - Cast return value of ioremap to (void __iomem *) to get rid of warning > concerning conversion of integer to pointer This one needs further inspection, I'd say. Grepping through the sources, I see that some platforms define ioremap to return 'void*' and some use 'void __iomem*'. The same class inconsistencies exist for iounmap(), I think the right thing is 'iounmap( void __iomem*)'. I found a comment that the value returned from ioremap() is not to be used as a virtual address, so it can't be used directly anyway, so a qualifier like volatile is not even necessary. The qualifier becomes necessary inside the functions that perform the actual IO like readb(), but everything outside should not even attempt to look at this pointer. Yes, on MIPS it can be used as virtual address AFAICT, some (broken?) code might even do so. If that code then relies on the volatile qualifier it will break... I went ahead and changed the functions in asm-mips/io.h, and my Au1100 board still seems to work as before. Several other architectures need these fixes, too, and several cases where the returnvalue of ioremap() or the parameter to iounmap() is cast falsely/unnecessarily are also present. Hacking on above stuff, I came across another thing that escapes me: inside functions like writes*() and reads*(), the the buffer to write to or read is taken as 'void*', then to be cast to 'volatile void*'. In the case of writes*(), IMHO the pointer should be const. In neither cases does it make sense to me to add the volatile to the pointer. What is the reason for this? Disclaimer: I'm far from being a kernel expert, so if I'm talking crap somebody please enlighten me. I just looked at the code and saw what to me looked inconsistent. > - Setup DB1X00_BOTH_BANKS, DB1X00_BOOT_ONLY, and DB1X00_USER_ONLY > defines in db1x00.h (used pb1550.h as an example) I copied over the code from the db1x00.h of Linux 2.4 to achieve the same. However, I didn't put this in any header because its use is limited to just one file, AFAICT. Hmm, I just looked a bit further, and now I wonder why there are so many drivers for Au1xx0 based boards. pb1550-flash.c and db1550-flash.c are almost similar, including the comment about the file they are based on (look at it, seems like search&replace gone amok). I haven't looked too far into it, but I really wonder if not at least db1x00-flash.c and db1550-flash.c could be merged with pb1xxx-flash.c and pb1550-flash.c, if not even all four could be merged into a single driver. Point is that the main difference seem to be the memory layout of the flash, all the rest seems generic enough. > I can see the partitions in /dev/mtd now, but I have not thoroughly > tested it yet to see if there are any other problems. Can you tell me how you created /dev/mtd? My version (Debian/x86) of MAKEDEV doesn't know these. Also, could you tell me how you configured your kernel? I have never seen an MTD working, so I don't even know if what I'm doing is supposed to work. :( Uli From root@linux-mips.org Mon Feb 21 11:57:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 12:22:17 +0000 (GMT) Received: (root@ultimateshells-pt.tunnel.tserv1.fmt.ipv6.he.net) by linux-mips.org id ; Mon, 21 Feb 2005 11:57:45 +0000 Received: from bay16-dav13.bay16.hotmail.com ([IPv6:::ffff:65.54.186.193]:60337 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Thu, 17 Feb 2005 03:22:14 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Feb 2005 19:22:00 -0800 Message-ID: Received: from 61.186.188.65 by BAY16-DAV13.phx.gbl with DAV; Thu, 17 Feb 2005 03:21:41 +0000 X-Originating-IP: [61.186.188.65] X-Originating-Email: [li_jiankun@hotmail.com] X-Sender: li_jiankun@hotmail.com Date: Thu, 17 Feb 2005 11:23:06 +0800 From: "=?GB2312?B?wO69qMCk?=" To: "linux-mips" Subject: error:Unhandled relocation of type 7 for X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 17 Feb 2005 03:22:00.0536 (UTC) FILETIME=[D7F3C580:01C5149F] Resent-From: root@ftp.linux-mips.org Resent-Date: Mon, 21 Feb 2005 11:57:45 +0000 Resent-To: 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: 7293 X-Approved-By: ralf@linux-mips.org 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: root@ftp.linux-mips.org Precedence: bulk X-list: linux-mips SGkgZXZlcnlvbmUsDQoNCiAgSSBoYXMgYmVlbiBkZXZlbG9waW5nIGRyaXZlcnMgZm9yIEFNRCBN SVBTIENQVSBBdTF4MDAsIGJ1dCBJIGVuY291bnRlZCBzb21lIHByb2JsZW1zLCBtYXliZSB5b3Ug Y291bGQgaGVscCBtZSENCg0KICBJIGNyb3NzLWNvbXBsaWxlIG15IGtlcm5lbCB3aXRoIG9wdGlv bnM6DQogIG1ha2UgQ0ZMQUdTPSItRF9fS0VSTkVMX18gLUkvd29yay9vcHQvdGFyZ2V0L3Jvb3Qv bGprL3BkYV9saW51eC9pbmNsdWRlIC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVduby10cmln cmFwaHMgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1mbm8tY29tbW9uIC1waXBlIC1mbm8tcGlj IC1tbm8tYWJpY2FsbHMgLW1sb25nLWNhbGxzIC1mb21pdC1mcmFtZS1wb2ludGVyIC1JIC93b3Jr L29wdC90YXJnZXQvcm9vdC9samsvcGRhX2xpbnV4L2luY2x1ZGUvYXNtL2djYyAtRyAwIC1tbm8t YWJpY2FsbHMgLWZuby1waWMgLXBpcGUgLW1jcHU9cjQ2MDAgLW1pcHMyIC1XYSwtLXRyYXAgIiAt QyAgYXJjaC9taXBzL2xpYg0KDQogIGFuZCB0aGVuIEkgY29tcGlsZSBteSBkcml2ZXIgbW9kdWxl cyB3aXRoIGZvbGxvd2luZyBvcHRpb25zOg0KICBtaXBzX2ZwX2xlLWdjYyAgLURfX0tFUk5FTF9f IC1ETU9EVUxFPTEgLUkvb3B0L3RhcmdldC9yb290L2xqay9wZGFfbGludXgvaW5jbHVkZSAtTzIg IC1ETElOVVggLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtZm9taXQtZnJhbWUtcG9pbnRlciAt V25vLXRyaWdyYXBocyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24gLXBpcGUg LURBTFNBX0JVSUxEIC1ub3N0ZGluYyAtaXdpdGhwcmVmaXggaW5jbHVkZSAtZm5vLXBpYyAtbW5v LWFiaWNhbGxzIC1tbG9uZy1jYWxscw0KDQogIGJ1dCB3aGVuIEkgd2FudCB0byBpbnNtb2QgdGhp cyBtb2R1bGVzLCB0aGUgZXJyb3JzIGNvbWU6DQogIGluc21vZCBzbmQtcGFnZS1hbGxvYy5vDQog IHNuZC1wYWdlLWFsbG9jLm86IFVuaGFuZGxlZCByZWxvY2F0aW9uIG9mIHR5cGUgNyBmb3INCiAg c25kLXBhZ2UtYWxsb2MubzogVW5oYW5kbGVkIHJlbG9jYXRpb24gb2YgdHlwZSA3IGZvcg0KICBz bmQtcGFnZS1hbGxvYy5vOiBVbmhhbmRsZWQgcmVsb2NhdGlvbiBvZiB0eXBlIDcgZm9yDQogIHNu ZC1wYWdlLWFsbG9jLm86IFVuaGFuZGxlZCByZWxvY2F0aW9uIG9mIHR5cGUgNyBmb3INCiAgc25k LXBhZ2UtYWxsb2MubzogVW5oYW5kbGVkIHJlbG9jYXRpb24gb2YgdHlwZSA3IGZvcg0KICBzbmQt cGFnZS1hbGxvYy5vOiBVbmhhbmRsZWQgcmVsb2NhdGlvbiBvZiB0eXBlIDcgZm9yDQogIHNuZC1w YWdlLWFsbG9jLm86IFVuaGFuZGxlZCByZWxvY2F0aW9uIG9mIHR5cGUgNyBmb3INCiAgc25kLXBh Z2UtYWxsb2MubzogVW5oYW5kbGVkIHJlbG9jYXRpb24gb2YgdHlwZSA3IGZvcg0KICBzbmQtcGFn ZS1hbGxvYy5vOiBVbmhhbmRsZWQgcmVsb2NhdGlvbiBvZiB0eXBlIDcgZm9yDQogIHNuZC1wYWdl LWFsbG9jLm86IFVuaGFuZGxlZCByZWxvY2F0aW9uIG9mIHR5cGUgNyBmb3INCiAgDQogIEhhdmUg eW91IGNvbWUgdXAgd2l0aCB0aGVzZSBwcm9ibGVtcz8gYW5kIENvdWxkIHlvdSBoZWxwIG1lIG9y IGdpdmUgbWUgc29tZSBzdWdnZXN0aW9ucz8NCiAgVGhhbmsgeW91IGluIGFkdmFuY2UhCQ0KDQqh oSAgICAgICAgICAgIGxpX2ppYW5rdW5AaG90bWFpbC5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGh MjAwNS0wMi0xNw0K // eompost 42140DF6:5644.1:yvahkzvcf From ica2_ts@csv.ica.uni-stuttgart.de Mon Feb 21 12:34:48 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 12:35:03 +0000 (GMT) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:47201 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 12:34:48 +0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1D3Clx-0006M5-00; Mon, 21 Feb 2005 13:34:45 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1D3Clx-0007xD-00; Mon, 21 Feb 2005 13:34:45 +0100 Date: Mon, 21 Feb 2005 13:34:45 +0100 To: ?????? Cc: linux-mips Subject: Re: error:Unhandled relocation of type 7 for Message-ID: <20050221123445.GT1757@rembrandt.csv.ica.uni-stuttgart.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 7294 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: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips ?????? wrote: > Hi everyone, > > I has been developing drivers for AMD MIPS CPU Au1x00, but I encounted some problems, maybe you could help me! > > I cross-complile my kernel with options: > make CFLAGS="-D__KERNEL__ -I/work/opt/target/root/ljk/pda_linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -fno-pic -mno-abicalls -mlong-calls -fomit-frame-pointer -I /work/opt/target/root/ljk/pda_linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap " -C arch/mips/lib > > and then I compile my driver modules with following options: > mips_fp_le-gcc -D__KERNEL__ -DMODULE=1 -I/opt/target/root/ljk/pda_linux/include -O2 -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -DALSA_BUILD -nostdinc -iwithprefix include -fno-pic -mno-abicalls -mlong-calls "-G 0 -mcpu=r4600 -mips2 -Wa,--trap" went missing. > but when I want to insmod this modules, the errors come: > insmod snd-page-alloc.o > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for > snd-page-alloc.o: Unhandled relocation of type 7 for And that's the result of it (missing -G 0, specifically). Thiemo From ralf@linux-mips.org Mon Feb 21 14:05:43 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 14:05:57 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:54811 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 14:05: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 j1LDxRtA014812; Mon, 21 Feb 2005 13:59:27 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1LDxQ31014811; Mon, 21 Feb 2005 13:59:26 GMT Date: Mon, 21 Feb 2005 13:59:26 +0000 From: Ralf Baechle To: Thiemo Seufer Cc: ?????? , linux-mips Subject: Re: error:Unhandled relocation of type 7 for Message-ID: <20050221135926.GB12444@linux-mips.org> References: <20050221123445.GT1757@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221123445.GT1757@rembrandt.csv.ica.uni-stuttgart.de> 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: 7295 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 21, 2005 at 01:34:45PM +0100, Thiemo Seufer wrote: > Date: Mon, 21 Feb 2005 13:34:45 +0100 > To: ?????? > Cc: linux-mips > Subject: Re: error:Unhandled relocation of type 7 for > Content-Type: text/plain; charset=us-ascii > From: Thiemo Seufer > > ?????? wrote: > > Hi everyone, > > > > I has been developing drivers for AMD MIPS CPU Au1x00, but I encounted some problems, maybe you could help me! > > > > I cross-complile my kernel with options: > > make CFLAGS="-D__KERNEL__ -I/work/opt/target/root/ljk/pda_linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -fno-pic -mno-abicalls -mlong-calls -fomit-frame-pointer -I /work/opt/target/root/ljk/pda_linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap " -C arch/mips/lib > > > > and then I compile my driver modules with following options: > > mips_fp_le-gcc -D__KERNEL__ -DMODULE=1 -I/opt/target/root/ljk/pda_linux/include -O2 -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -DALSA_BUILD -nostdinc -iwithprefix include -fno-pic -mno-abicalls -mlong-calls > > "-G 0 -mcpu=r4600 -mips2 -Wa,--trap" went missing. > > > but when I want to insmod this modules, the errors come: > > insmod snd-page-alloc.o > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > snd-page-alloc.o: Unhandled relocation of type 7 for > > And that's the result of it (missing -G 0, specifically). GP Optimization has _never_ done anything useful on Linux as such I blame the person who put that -G 8 crap into gcc. Ralf From eckhardt@satorlaser.com Mon Feb 21 15:07:00 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 15:07:17 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.171]:9423 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 15:07:00 +0000 Received: from [213.39.254.66] (helo=tuxator.satorlaser-intern.com) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1D3F9E2yB3-0004Sr; Mon, 21 Feb 2005 16:06:56 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch]small bug in PCMCIA on DB1x00 boards Date: Mon, 21 Feb 2005 16:09:42 +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: <200502211609.42963.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: 7296 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 Hello! Another patch that fixes some small glitches in the PCMCIA code. Note: I have not (yet) been able to get the compact-flash card to be recognised on my board (it is supposed to appear as PCMCIA/IDE device, right?) but this patch addresses three things that should be obvious without testing. Yes, I know, those are famous last words, but look yourselves. ;) BTW: I found that au1000_xxs1500.c and au1000_pb1x00.c can't compile due changed PCMCIA interfaces, some functions (socket_state, configure_socket) were changed from returning void to returning int and changed their parameters. These two are also the last two files that use struct pcmcia_configure. Maybe copying that struct to the .c files and adding an #error with a proper comment would be a good idea? Uli Changes: * removed struct pcmcia_irqs, which was unused * added an explicit BUG() in a place marked with "should never happen" * added a missing early return when the card-voltage could not be detected, as a comment above already says. --- Index: au1000_db1x00.c =================================================================== RCS file: /home/cvs/linux/drivers/pcmcia/au1000_db1x00.c,v retrieving revision 1.6 diff -u -r1.6 au1000_db1x00.c --- au1000_db1x00.c 14 Oct 2004 06:24:25 -0000 1.6 +++ au1000_db1x00.c 21 Feb 2005 14:13:21 -0000 @@ -91,7 +91,9 @@ vs = (bcsr->status & 0xC)>>2; inserted = !(bcsr->status & (1<<5)); break; - default:/* should never happen */ + default: + /* should never happen */ + BUG(); return; } @@ -109,8 +111,8 @@ break; default: /* return without setting 'detect' */ - printk(KERN_ERR "db1x00 bad VS (%d)\n", - vs); + printk(KERN_ERR "db1x00 bad VS (%d)\n", vs); + return; } state->detect = 1; state->ready = 1; Index: au1000_generic.h =================================================================== RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.h,v retrieving revision 1.4 diff -u -r1.4 au1000_generic.h --- au1000_generic.h 19 Oct 2004 07:26:37 -0000 1.4 +++ au1000_generic.h 21 Feb 2005 14:13:21 -0000 @@ -78,13 +78,6 @@ reset: 1; }; -struct pcmcia_irqs { - int sock; - int irq; - const char *str; -}; - - struct au1000_pcmcia_socket { struct pcmcia_socket socket; From clem.taylor@gmail.com Mon Feb 21 16:33:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 16:33:56 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.207]:134 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 16:33:38 +0000 Received: by wproxy.gmail.com with SMTP id 57so768361wri for ; Mon, 21 Feb 2005 08:33:29 -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=rosvcAe8PtDB2n9I9TZI+yEH6TmhCnvjvYwgW2V8vUpnoJ/nTPdWcFamhjdDNB5kd21hy9zdTi1aLG5jWbuqL/aaWIw/Y2qJOEVIzHNUhR3e2vgstPzvwHFGNRjKlMNF3i+7eN5EsqGWrF9i1mA6tM/5p27Wtw6Nf5Yp1ZyIhJo= Received: by 10.54.35.68 with SMTP id i68mr40435wri; Mon, 21 Feb 2005 08:33:29 -0800 (PST) Received: by 10.54.41.3 with HTTP; Mon, 21 Feb 2005 08:33:29 -0800 (PST) Message-ID: Date: Mon, 21 Feb 2005 11:33:29 -0500 From: Clem Taylor Reply-To: Clem Taylor To: linux-mips@linux-mips.org Subject: compiling yamon for Au1550 with a recent toolchain? 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: 7297 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: clem.taylor@gmail.com Precedence: bulk X-list: linux-mips This isn't completely on topic, but it is a step on the way. I'm getting ready for my Au1550 based hardware that will be back from assembly soon. I'm trying to get the AMD provided yamon source to compile. I'm using gcc 3.4.3 and bintools 2.15.94.0.2. After a few tweeks to the makefile, yamon compiles but fails to link: mips-ld -G 0 -T ./../link/link_el.xn -o ./yamon-02.23DB1550_el.elf -Map ... mips-ld: section .data [000000009fc3d650 -> 000000009fc40faf] overlaps section .rodata.str1.4 [000000009fc3d650 -> 000000009fc47197] mips-ld: ./yamon-02.23DB1550_el.elf: section .rodata.str1.4 lma 0x9fc3d650 overlaps previous sections mips-ld: ./yamon-02.23DB1550_el.elf: section .rodata.cst4 lma 0x9fc47198 overlaps previous sections The linker command file (bin/link/link_el.xn) puts .data and .rodata in _etext. I changed the *(.rodata) to *(.rodata*) in the link_el.xn, but that didn't help. Any ideas what might be going on? Has anyone tried compiling this yamon with a recent gcc/bintools? Thanks, Clem From ralf@linux-mips.org Mon Feb 21 16:40:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 16:40:46 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:58133 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 16:40:31 +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 j1LGXond020523; Mon, 21 Feb 2005 16:33:50 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1LGXopm020522; Mon, 21 Feb 2005 16:33:50 GMT Date: Mon, 21 Feb 2005 16:33:50 +0000 From: Ralf Baechle To: Peter Horton Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 2.6] Cobalt fixes [5 of 6] Message-ID: <20050221163350.GF14692@linux-mips.org> References: <20050220150103.GF26582@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050220150103.GF26582@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: 7298 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 20, 2005 at 03:01:03PM +0000, Peter Horton wrote: > Fix Qube/RaQ PIO IDE to prevent D-cache aliasing problems. This really shouldn't be in machine-specific code. A while ago somebody did post a patch to the generic code which I had minor objections on. Gotta dig it up and fix it ... Ralf From ppopov@embeddedalley.com Mon Feb 21 17:26:29 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 17:26:45 +0000 (GMT) Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:33470 "HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Mon, 21 Feb 2005 17:26:29 +0000 Received: from unknown (HELO ?10.2.2.62?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 21 Feb 2005 17:26:26 -0000 Message-ID: <421A19B6.6050102@embeddedalley.com> Date: Mon, 21 Feb 2005 09:26: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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Eckhardt CC: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [patch]small bug in PCMCIA on DB1x00 boards References: <200502211609.42963.eckhardt@satorlaser.com> In-Reply-To: <200502211609.42963.eckhardt@satorlaser.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7299 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 Ulrich Eckhardt wrote: > Hello! > > Another patch that fixes some small glitches in the PCMCIA code. > > Note: I have not (yet) been able to get the compact-flash card to be > recognised on my board (it is supposed to appear as PCMCIA/IDE device, > right?) but this patch addresses three things that should be obvious without > testing. Yes, I know, those are famous last words, but look yourselves. ;) > > BTW: I found that au1000_xxs1500.c and au1000_pb1x00.c can't compile due > changed PCMCIA interfaces, I've updated the db1x00 driver only. It should be easy to update the rest of the boards, using the db1x as an example. Pete some functions (socket_state, configure_socket) > were changed from returning void to returning int and changed their > parameters. These two are also the last two files that use struct > pcmcia_configure. Maybe copying that struct to the .c files and adding an > #error with a proper comment would be a good idea? > > Uli > > > Changes: > * removed struct pcmcia_irqs, which was unused > * added an explicit BUG() in a place marked with "should never happen" > * added a missing early return when the card-voltage could not be > detected, as a comment above already says. > > --- > > Index: au1000_db1x00.c > =================================================================== > RCS file: /home/cvs/linux/drivers/pcmcia/au1000_db1x00.c,v > retrieving revision 1.6 > diff -u -r1.6 au1000_db1x00.c > --- au1000_db1x00.c 14 Oct 2004 06:24:25 -0000 1.6 > +++ au1000_db1x00.c 21 Feb 2005 14:13:21 -0000 > @@ -91,7 +91,9 @@ > vs = (bcsr->status & 0xC)>>2; > inserted = !(bcsr->status & (1<<5)); > break; > - default:/* should never happen */ > + default: > + /* should never happen */ > + BUG(); > return; > } > > @@ -109,8 +111,8 @@ > break; > default: > /* return without setting 'detect' */ > - printk(KERN_ERR "db1x00 bad VS (%d)\n", > - vs); > + printk(KERN_ERR "db1x00 bad VS (%d)\n", vs); > + return; > } > state->detect = 1; > state->ready = 1; > Index: au1000_generic.h > =================================================================== > RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.h,v > retrieving revision 1.4 > diff -u -r1.4 au1000_generic.h > --- au1000_generic.h 19 Oct 2004 07:26:37 -0000 1.4 > +++ au1000_generic.h 21 Feb 2005 14:13:21 -0000 > @@ -78,13 +78,6 @@ > reset: 1; > }; > > -struct pcmcia_irqs { > - int sock; > - int irq; > - const char *str; > -}; > - > - > struct au1000_pcmcia_socket { > struct pcmcia_socket socket; > > > From gilad@romat.com Mon Feb 21 18:15:18 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 18:15:33 +0000 (GMT) Received: from mail.romat.com ([IPv6:::ffff:212.143.245.3]:61448 "EHLO mail.romat.com") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 18:15:18 +0000 Received: from localhost (localhost.lan [127.0.0.1]) by mail.romat.com (Postfix) with ESMTP id 0CEB8EB2D3; Mon, 21 Feb 2005 20:15:12 +0200 (IST) Received: from mail.romat.com ([127.0.0.1]) by localhost (mail.romat.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15326-01; Mon, 21 Feb 2005 20:15:05 +0200 (IST) Received: from [192.168.1.199] (linux.lan [192.168.1.199]) by mail.romat.com (Postfix) with ESMTP id 7F53CEB2B6; Mon, 21 Feb 2005 20:15:05 +0200 (IST) Message-ID: <421A2526.6020806@romat.com> Date: Mon, 21 Feb 2005 20:15:02 +0200 From: Gilad Rom User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clem Taylor Cc: linux-mips@linux-mips.org Subject: Re: compiling yamon for Au1550 with a recent toolchain? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at romat.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: 7300 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 I have. I can tell you it required a lot of hacking, most of which I haven't written down. I can send you my sources if you'd like. They're hardwired for Au1500/Little Endian, but they build ;) Shoudn't take long to change the actual build type. Gilad. Clem Taylor wrote: > This isn't completely on topic, but it is a step on the way. I'm > getting ready for my Au1550 based hardware that will be back from > assembly soon. I'm trying to get the AMD provided yamon source to > compile. I'm using gcc 3.4.3 and bintools 2.15.94.0.2. After a few > tweeks to the makefile, yamon compiles but fails to link: > > mips-ld -G 0 -T ./../link/link_el.xn -o ./yamon-02.23DB1550_el.elf -Map ... > mips-ld: section .data [000000009fc3d650 -> 000000009fc40faf] overlaps > section .rodata.str1.4 [000000009fc3d650 -> 000000009fc47197] > mips-ld: ./yamon-02.23DB1550_el.elf: section .rodata.str1.4 lma > 0x9fc3d650 overlaps previous sections > mips-ld: ./yamon-02.23DB1550_el.elf: section .rodata.cst4 lma > 0x9fc47198 overlaps previous sections > > The linker command file (bin/link/link_el.xn) puts .data and .rodata > in _etext. I changed the *(.rodata) to *(.rodata*) in the link_el.xn, > but that didn't help. > > Any ideas what might be going on? Has anyone tried compiling this > yamon with a recent gcc/bintools? > > Thanks, > Clem > > From jgreen@users.sourceforge.net Mon Feb 21 23:56:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Feb 2005 23:56:39 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:56226 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Mon, 21 Feb 2005 23:56:24 +0000 Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35]) by mail-relay.infostations.net (Postfix) with ESMTP id 518749F80D; Mon, 21 Feb 2005 15:56:25 -0800 (PST) Received: from host-66-81-139-234.rev.o1.com ([66.81.139.234]) by seriyu.infostations.net with esmtp (Exim 4.41 #1) id 1D3NPY-0007EH-LD; Mon, 21 Feb 2005 15:56:21 -0800 Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board From: Josh Green To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org In-Reply-To: <200502211144.58470.eckhardt@satorlaser.com> References: <1108962105.6611.24.camel@SillyPuddy.localdomain> <200502211144.58470.eckhardt@satorlaser.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SZGJ3UmGDBRQ8vmlpeKS" Date: Mon, 21 Feb 2005 15:57:55 -0800 Message-Id: <1109030275.13988.21.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: 7302 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 Content-Length: 3039 Lines: 92 --=-SZGJ3UmGDBRQ8vmlpeKS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-21 at 11:44 +0100, Ulrich Eckhardt wrote: > Disclaimer: I'm far from being a kernel expert, so if I'm talking crap=20 > somebody please enlighten me. I just looked at the code and saw what to m= e=20 > looked inconsistent. >=20 I'm no kernel expert either, so no comments from me :) > > I can see the partitions in /dev/mtd now, but I have not thoroughly > > tested it yet to see if there are any other problems. >=20 > Can you tell me how you created /dev/mtd? My version (Debian/x86) of MAKE= DEV=20 > doesn't know these. Also, could you tell me how you configured your kerne= l? I=20 > have never seen an MTD working, so I don't even know if what I'm doing is= =20 > supposed to work. :( >=20 I used a CVS checkout of buildroot from linux-mips.org to build my initial cross compile x86->mips tool chain and root file system. I'm now building most of the software separately (kernel, busybox, hostap, wireless-tools, wavemon, pcmcia-cs, etc) since I've found it to be more flexible. So to answer your question, buildroot made the device files for me. You could easily create them though using mknod: mknod /dev/mtdblock0 b 31 0 mknod /dev/mtdblock1 b 31 1 mknod /dev/mtdblock2 b 31 2 mknod /dev/mtdblock3 b 31 3 You could do the same for the mtd0-3 devices, although I don't have use for them myself. They are major 90, minor 0, 2, 4, 6 for mtd0,1,2,3 respectively. Another note concerning the MTD stuff. It did not work for me until I enabled some chip drivers in the RAM/ROM/Flash chip drivers section, specifically: <*> Detect flash chips by Common Flash Interface (CFI) probe <*> Support for AMD/Fujitsu flash chips Some additional options I have enabled in the MTD section: [*] MTD partitioning support <*> MTD concatenating support (I think this is might be needed for the case where you enable both user and boot chips, but I wouldn't be surprised if I'm wrong about that) <*> Caching block device access to MTD devices Once I had that enabled I now see the "user FS", "kernel", "yamon" MTD partitions in the kernel dmesg output. > Uli >=20 >=20 I am now building a compressed kernel (using some patches I found from Pete Popov in a mailing list archive here: http://www.spinics.net/lists/mips/msg18196.html) and have successfully flashed and booted it by copying it to the correct mtdblock device. I've also got jffs2 working on the User FS partition, but I get a whole bunch of errors when it boots (regardless it still seems to function). I'll post these in another thread if I can't get it resolved. Best regards, Josh Green --=-SZGJ3UmGDBRQ8vmlpeKS 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) iD8DBQBCGnWCRoMuWKCcbgQRAiSxAKC0h4AhQDK+/M6CV+InShXQluHzqgCfVHvy voSn20raKP2jxrT+zvaO75w= =3dUJ -----END PGP SIGNATURE----- --=-SZGJ3UmGDBRQ8vmlpeKS-- From jgreen@users.sourceforge.net Tue Feb 22 06:05:21 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 06:05:37 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:30391 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Tue, 22 Feb 2005 06:05:21 +0000 Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35]) by mail-relay.infostations.net (Postfix) with ESMTP id E5DC79F842; Mon, 21 Feb 2005 22:05:21 -0800 (PST) Received: from host-66-81-130-156.rev.o1.com ([66.81.130.156]) by seriyu.infostations.net with esmtp (Exim 4.41 #1) id 1D3TAb-0007HC-Pi; Mon, 21 Feb 2005 22:05:18 -0800 Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board From: Josh Green To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org In-Reply-To: <1109030275.13988.21.camel@SillyPuddy.localdomain> References: <1108962105.6611.24.camel@SillyPuddy.localdomain> <200502211144.58470.eckhardt@satorlaser.com> <1109030275.13988.21.camel@SillyPuddy.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kF94/OSAb9oDK4NZfMbc" Date: Mon, 21 Feb 2005 22:06:52 -0800 Message-Id: <1109052412.20045.6.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: 7303 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 Content-Length: 1569 Lines: 44 --=-kF94/OSAb9oDK4NZfMbc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-02-21 at 15:57 -0800, Josh Green wrote: >=20 > I've also got jffs2 working on the User FS partition, but I get a whole > bunch of errors when it boots (regardless it still seems to function). > I'll post these in another thread if I can't get it resolved. >=20 Just to complete this thread, I did figure out what my trouble was. I erroneously thought that I didn't need the mtd0-3 dev support, but I ended up needing it for the flash_erase (sometimes called just "erase") command, which was what I had to run before my jffs2 errors went away. Things seem to be working fine now :) Make sure to erase the partition using the correct count, I had to do: flash_erase /dev/mtd0 0 0xe0 The first parameter is the offset, the second is the number of "erase size" blocks to erase (likely different for your case). This can be found from your total flash size divided by the erase size (cat /proc/mtd for this info). Gee, funny how things work when you do it right :) I must say documentation is lacking for the mtd tools though, I had to look at the code, sheesh, ha ha. Cheers. Josh Green --=-kF94/OSAb9oDK4NZfMbc 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) iD8DBQBCGsv8RoMuWKCcbgQRAuHDAJ9GOOCDN6mIenwDcgRorf9GLaoGRQCgldeA dXMKnAlEJAJTXJnrUfTkMNE= =vdxD -----END PGP SIGNATURE----- --=-kF94/OSAb9oDK4NZfMbc-- From ppopov@embeddedalley.com Tue Feb 22 07:25:54 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 07:26:16 +0000 (GMT) Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:39356 "HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP id ; Tue, 22 Feb 2005 07:25:54 +0000 Received: from unknown (HELO ?10.2.2.64?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp001.bizmail.yahoo.com with SMTP; 22 Feb 2005 07:25:50 -0000 Message-ID: <421ADE76.5020905@embeddedalley.com> Date: Mon, 21 Feb 2005 23:25:42 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board References: <1108962105.6611.24.camel@SillyPuddy.localdomain> <200502211144.58470.eckhardt@satorlaser.com> <1109030275.13988.21.camel@SillyPuddy.localdomain> <1109052412.20045.6.camel@SillyPuddy.localdomain> In-Reply-To: <1109052412.20045.6.camel@SillyPuddy.localdomain> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040808010503020405080103" 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: 7304 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: 26542 Lines: 967 This is a multi-part message in MIME format. --------------040808010503020405080103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here is a 2.6 patch that gets rid of all the Au1x mapping files and replaces them with a single file. The driver doesn't check for different flash densities supported by the Db1x boards, but it turns out AMD always shipped the boards with a single configuration only. This file should work on all boards. And I think it should work with 2.4 as well, as long as the entire tree is patched. Though, I need to first update the 2.4 style Config.in in the mtd tree. Pete Josh Green wrote: > On Mon, 2005-02-21 at 15:57 -0800, Josh Green wrote: > >>I've also got jffs2 working on the User FS partition, but I get a whole >>bunch of errors when it boots (regardless it still seems to function). >>I'll post these in another thread if I can't get it resolved. >> > > > Just to complete this thread, I did figure out what my trouble was. I > erroneously thought that I didn't need the mtd0-3 dev support, but I > ended up needing it for the flash_erase (sometimes called just "erase") > command, which was what I had to run before my jffs2 errors went away. > Things seem to be working fine now :) Make sure to erase the partition > using the correct count, I had to do: > > flash_erase /dev/mtd0 0 0xe0 > > The first parameter is the offset, the second is the number of "erase > size" blocks to erase (likely different for your case). This can be > found from your total flash size divided by the erase size > (cat /proc/mtd for this info). Gee, funny how things work when you do > it right :) I must say documentation is lacking for the mtd tools > though, I had to look at the code, sheesh, ha ha. Cheers. > Josh Green > --------------040808010503020405080103 Content-Type: text/plain; name="alchemy_mtd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="alchemy_mtd.patch" diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/db1000_defconfig linux-2.6-dev/arch/mips/configs/db1000_defconfig --- linux-2.6-orig/arch/mips/configs/db1000_defconfig 2005-01-30 21:44:53.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/db1000_defconfig 2005-02-21 22:27:29.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:02:48 2005 +# Mon Feb 21 22:20:54 2005 # CONFIG_MIPS=y @@ -182,6 +182,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -197,7 +198,67 @@ # # Memory Technology Devices (MTD) # -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_CONCAT is not set +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_ALCHEMY=y + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set # # Parallel port support @@ -486,7 +547,8 @@ # Watchdog Cards # # CONFIG_WATCHDOG is not set -CONFIG_RTC=y +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set @@ -634,6 +696,8 @@ # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +# CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/db1100_defconfig linux-2.6-dev/arch/mips/configs/db1100_defconfig --- linux-2.6-orig/arch/mips/configs/db1100_defconfig 2005-01-30 21:44:53.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/db1100_defconfig 2005-02-21 22:34:42.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:02:50 2005 +# Mon Feb 21 22:33:43 2005 # CONFIG_MIPS=y @@ -146,7 +146,7 @@ # CONFIG_PAGE_SIZE_16KB is not set # CONFIG_PAGE_SIZE_64KB is not set CONFIG_CPU_HAS_PREFETCH=y -# CONFIG_64BIT_PHYS_ADDR is not set +CONFIG_64BIT_PHYS_ADDR=y # CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_LLSC=y CONFIG_CPU_HAS_SYNC=y @@ -180,6 +180,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -195,7 +196,67 @@ # # Memory Technology Devices (MTD) # -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_CONCAT is not set +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_ALCHEMY=y + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set # # Parallel port support @@ -481,7 +542,8 @@ # Watchdog Cards # # CONFIG_WATCHDOG is not set -CONFIG_RTC=y +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set @@ -629,6 +691,8 @@ # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +# CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/db1500_defconfig linux-2.6-dev/arch/mips/configs/db1500_defconfig --- linux-2.6-orig/arch/mips/configs/db1500_defconfig 2005-01-30 21:44:53.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/db1500_defconfig 2005-02-21 21:48:46.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:02:54 2005 +# Mon Feb 21 21:33:53 2005 # CONFIG_MIPS=y @@ -104,7 +104,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y -CONFIG_DMA_COHERENT=y +CONFIG_DMA_NONCOHERENT=y CONFIG_MIPS_DISABLE_OBSOLETE_IDE=y # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y @@ -190,6 +190,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -253,9 +254,7 @@ # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set -CONFIG_MTD_DB1X00=y -CONFIG_MTD_DB1X00_BOOT=y -CONFIG_MTD_DB1X00_USER=y +CONFIG_MTD_ALCHEMY=y # # Self-contained MTD device drivers @@ -617,7 +616,8 @@ # Watchdog Cards # # CONFIG_WATCHDOG is not set -CONFIG_RTC=y +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/db1550_defconfig linux-2.6-dev/arch/mips/configs/db1550_defconfig --- linux-2.6-orig/arch/mips/configs/db1550_defconfig 2005-01-30 21:44:53.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/db1550_defconfig 2005-02-21 22:46:50.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:02:57 2005 +# Mon Feb 21 22:40:28 2005 # CONFIG_MIPS=y @@ -104,7 +104,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y -CONFIG_DMA_COHERENT=y +CONFIG_DMA_NONCOHERENT=y CONFIG_MIPS_DISABLE_OBSOLETE_IDE=y # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y @@ -190,6 +190,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -252,9 +253,7 @@ # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set -CONFIG_MTD_DB1550=y -CONFIG_MTD_DB1550_BOOT=y -CONFIG_MTD_DB1550_USER=y +CONFIG_MTD_ALCHEMY=y # # Self-contained MTD device drivers diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/pb1100_defconfig linux-2.6-dev/arch/mips/configs/pb1100_defconfig --- linux-2.6-orig/arch/mips/configs/pb1100_defconfig 2005-01-30 21:44:55.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/pb1100_defconfig 2005-02-21 22:00:40.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:03:55 2005 +# Mon Feb 21 22:00:32 2005 # CONFIG_MIPS=y @@ -148,7 +148,7 @@ # CONFIG_PAGE_SIZE_16KB is not set # CONFIG_PAGE_SIZE_64KB is not set CONFIG_CPU_HAS_PREFETCH=y -# CONFIG_64BIT_PHYS_ADDR is not set +CONFIG_64BIT_PHYS_ADDR=y # CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_LLSC=y CONFIG_CPU_HAS_SYNC=y @@ -184,6 +184,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -246,9 +247,7 @@ # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set -CONFIG_MTD_PB1100=y -CONFIG_MTD_PB1500_BOOT=y -CONFIG_MTD_PB1500_USER=y +CONFIG_MTD_ALCHEMY=y # # Self-contained MTD device drivers @@ -547,7 +546,8 @@ # Watchdog Cards # # CONFIG_WATCHDOG is not set -CONFIG_RTC=y +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/pb1500_defconfig linux-2.6-dev/arch/mips/configs/pb1500_defconfig --- linux-2.6-orig/arch/mips/configs/pb1500_defconfig 2005-01-30 21:44:55.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/pb1500_defconfig 2005-02-21 22:11:42.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:03:58 2005 +# Mon Feb 21 22:05:25 2005 # CONFIG_MIPS=y @@ -104,7 +104,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y -CONFIG_DMA_COHERENT=y +CONFIG_DMA_NONCOHERENT=y # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y @@ -191,6 +191,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -206,7 +207,68 @@ # # Memory Technology Devices (MTD) # -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_CONCAT is not set +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_ALCHEMY=y + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_PMC551 is not set +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set # # Parallel port support @@ -726,6 +788,8 @@ # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +# CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set diff -Naur --exclude=CVS linux-2.6-orig/arch/mips/configs/pb1550_defconfig linux-2.6-dev/arch/mips/configs/pb1550_defconfig --- linux-2.6-orig/arch/mips/configs/pb1550_defconfig 2005-01-30 21:44:55.000000000 -0800 +++ linux-2.6-dev/arch/mips/configs/pb1550_defconfig 2005-02-21 22:19:48.000000000 -0800 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2 -# Sun Jan 30 19:04:01 2005 +# Mon Feb 21 22:19:39 2005 # CONFIG_MIPS=y @@ -104,7 +104,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y -CONFIG_DMA_COHERENT=y +CONFIG_DMA_NONCOHERENT=y CONFIG_MIPS_DISABLE_OBSOLETE_IDE=y # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y @@ -191,6 +191,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_TRAD_SIGNALS=y +# CONFIG_PM is not set # # Device Drivers @@ -206,7 +207,68 @@ # # Memory Technology Devices (MTD) # -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_CONCAT is not set +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_ALCHEMY=y + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_PMC551 is not set +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set # # Parallel port support @@ -718,6 +780,8 @@ # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +# CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set diff -Naur --exclude=CVS linux-2.6-orig/drivers/mtd/maps/alchemy-flash.c linux-2.6-dev/drivers/mtd/maps/alchemy-flash.c --- linux-2.6-orig/drivers/mtd/maps/alchemy-flash.c 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6-dev/drivers/mtd/maps/alchemy-flash.c 2005-02-21 21:35:35.000000000 -0800 @@ -0,0 +1,189 @@ +/* + * Flash memory access on AMD Alchemy evaluation boards + * + * $Id: alchey-flash.c,v 1.0 2004/11/04 13:24:14 gleixner Exp $ + * + * (C) 2003, 2004 Pete Popov + * + */ + +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + +#ifdef DEBUG_RW +#define DBG(x...) printk(x) +#else +#define DBG(x...) +#endif + +#ifdef CONFIG_MIPS_PB1000 +#define BOARD_MAP_NAME "Pb1000 Flash" +#define BOARD_FLASH_SIZE 0x00800000 /* 8MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_PB1500 +#define BOARD_MAP_NAME "Pb1500 Flash" +#define BOARD_FLASH_SIZE 0x04000000 /* 64MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_PB1100 +#define BOARD_MAP_NAME "Pb1100 Flash" +#define BOARD_FLASH_SIZE 0x04000000 /* 64MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_PB1550 +#define BOARD_MAP_NAME "Pb1550 Flash" +#define BOARD_FLASH_SIZE 0x08000000 /* 128MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_PB1200 +#define BOARD_MAP_NAME "Pb1200 Flash" +#define BOARD_FLASH_SIZE 0x08000000 /* 128MB */ +#define BOARD_FLASH_WIDTH 2 /* 16-bits */ +#endif + +#ifdef CONFIG_MIPS_DB1000 +#define BOARD_MAP_NAME "Db1000 Flash" +#define BOARD_FLASH_SIZE 0x02000000 /* 32MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_DB1500 +#define BOARD_MAP_NAME "Db1500 Flash" +#define BOARD_FLASH_SIZE 0x02000000 /* 32MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_DB1100 +#define BOARD_MAP_NAME "Db1100 Flash" +#define BOARD_FLASH_SIZE 0x02000000 /* 32MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_DB1550 +#define BOARD_MAP_NAME "Db1550 Flash" +#define BOARD_FLASH_SIZE 0x08000000 /* 128MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#endif + +#ifdef CONFIG_MIPS_DB1200 +#define BOARD_MAP_NAME "Db1200 Flash" +#define BOARD_FLASH_SIZE 0x04000000 /* 64MB */ +#define BOARD_FLASH_WIDTH 2 /* 16-bits */ +#endif + +#ifdef CONFIG_MIPS_HYDROGEN3 +#define BOARD_MAP_NAME "Hydrogen3 Flash" +#define BOARD_FLASH_SIZE 0x02000000 /* 32MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#define USE_LOCAL_ACCESSORS /* why? */ +#endif + +#ifdef CONFIG_MIPS_BOSPORUS +#define BOARD_MAP_NAME "Bosporus Flash" +#define BOARD_FLASH_SIZE 0x01000000 /* 16MB */ +#define BOARD_FLASH_WIDTH 2 /* 16-bits */ +#endif + +#ifdef CONFIG_MIPS_MIRAGE +#define BOARD_MAP_NAME "Mirage Flash" +#define BOARD_FLASH_SIZE 0x04000000 /* 64MB */ +#define BOARD_FLASH_WIDTH 4 /* 32-bits */ +#define USE_LOCAL_ACCESSORS /* why? */ +#endif + +static struct map_info alchemy_map = { + .name = BOARD_MAP_NAME, +}; + +static struct mtd_partition alchemy_partitions[] = { + { + .name = "User FS", + .size = BOARD_FLASH_SIZE - 0x00400000, + .offset = 0x0000000 + },{ + .name = "YAMON", + .size = 0x0100000, + .offset = MTDPART_OFS_APPEND, + .mask_flags = MTD_WRITEABLE + },{ + .name = "raw kernel", + .size = (0x300000 - 0x40000), /* last 256KB is yamon env */ + .offset = MTDPART_OFS_APPEND, + } +}; + +#define NB_OF(x) (sizeof(x)/sizeof(x[0])) + +static struct mtd_info *mymtd; + +int __init alchemy_mtd_init(void) +{ + struct mtd_partition *parts; + int nb_parts = 0; + unsigned long window_addr; + unsigned long window_size; + + /* Default flash buswidth */ + alchemy_map.bankwidth = BOARD_FLASH_WIDTH; + + window_addr = 0x20000000 - BOARD_FLASH_SIZE; + window_size = BOARD_FLASH_SIZE; +#ifdef CONFIG_MIPS_MIRAGE_WHY + /* Boot ROM flash bank only; no user bank */ + window_addr = 0x1C000000; + window_size = 0x04000000; + /* USERFS from 0x1C00 0000 to 0x1FC00000 */ + alchemy_partitions[0].size = 0x03C00000; +#endif + + /* + * Static partition definition selection + */ + parts = alchemy_partitions; + nb_parts = NB_OF(alchemy_partitions); + alchemy_map.size = window_size; + + /* + * Now let's probe for the actual flash. Do it here since + * specific machine settings might have been set above. + */ + printk(KERN_NOTICE BOARD_MAP_NAME ": probing %d-bit flash bus\n", + alchemy_map.bankwidth*8); + alchemy_map.virt = ioremap(window_addr, window_size); + mymtd = do_map_probe("cfi_probe", &alchemy_map); + if (!mymtd) return -ENXIO; + mymtd->owner = THIS_MODULE; + + add_mtd_partitions(mymtd, parts, nb_parts); + return 0; +} + +static void __exit alchemy_mtd_cleanup(void) +{ + if (mymtd) { + del_mtd_partitions(mymtd); + map_destroy(mymtd); + iounmap((void *) alchemy_map.virt); + } +} + +module_init(alchemy_mtd_init); +module_exit(alchemy_mtd_cleanup); + +MODULE_AUTHOR("Embedded Alley Solutions, Inc"); +MODULE_DESCRIPTION(BOARD_MAP_NAME " MTD driver"); +MODULE_LICENSE("GPL"); diff -Naur --exclude=CVS linux-2.6-orig/drivers/mtd/maps/Kconfig linux-2.6-dev/drivers/mtd/maps/Kconfig --- linux-2.6-orig/drivers/mtd/maps/Kconfig 2005-01-30 21:45:19.000000000 -0800 +++ linux-2.6-dev/drivers/mtd/maps/Kconfig 2005-02-21 22:13:00.000000000 -0800 @@ -207,52 +207,6 @@ help Support for flash chips on NETtel/SecureEdge/SnapGear boards. -config MTD_PB1550 - tristate "Flash devices on Alchemy PB1550 board" - depends on MIPS && MIPS_PB1550 - help - Flash memory access on Alchemy Pb1550 board - -config MTD_PB1550_BOOT - bool "PB1550 boot flash device" - depends on MTD_PB1550 - help - Use the first of the two 64MiB flash banks on Pb1550 board. - You can say 'Y' to both this and 'MTD_PB1550_USER' below, to use - both banks. - -config MTD_PB1550_USER - bool "PB1550 user flash device" - depends on MTD_PB1550 - default y if MTD_PB1550_BOOT = n - help - Use the second of the two 64MiB flash banks on Pb1550 board. - You can say 'Y' to both this and 'MTD_PB1550_BOOT' above, to use - both banks. - -config MTD_DB1550 - tristate "Flash devices on Alchemy DB1550 board" - depends on MIPS && MIPS_DB1550 - help - Flash memory access on Alchemy Db1550 board - -config MTD_DB1550_BOOT - bool "DB1550 boot flash device" - depends on MTD_DB1550 - help - Use the first of the two 64MiB flash banks on Db1550 board. - You can say 'Y' to both this and 'MTD_DB1550_USER' below, to use - both banks. - -config MTD_DB1550_USER - bool "DB1550 user flash device" - depends on MTD_DB1550 - default y if MTD_DB1550_BOOT = n - help - Use the second of the two 64MiB flash banks on Db1550 board. - You can say 'Y' to both this and 'MTD_DB1550_BOOT' above, to use - both banks. - config MTD_DILNETPC tristate "CFI Flash device mapped on DIL/Net PC" depends on X86 && MTD_CONCAT && MTD_PARTITIONS && MTD_CFI_INTELEXT @@ -328,67 +282,11 @@ Mapping for the Flaga digital module. If you don't have one, ignore this setting. -config MTD_PB1000 - tristate "Pb1000 Boot Flash device" - depends on MIPS && MIPS_PB1000 - help - Flash memory access on Alchemy Pb1000 - -config MTD_PB1100 - tristate "Pb1100 Flash device" - depends on MIPS && MIPS_PB1100 - help - Flash memory access on Alchemy Pb1100 - -config MTD_PB1500 - tristate "Pb1500 Flash device" - depends on MIPS && MIPS_PB1500 - help - Flash memory access on Alchemy Pb1500 - -config MTD_PB1500_BOOT - bool "Pb1100/Pb1500 Boot Flash device" - depends on MIPS && (MTD_PB1500 || MTD_PB1100) - help - Use the first of the two 32MB flash banks on Pb1100/Pb1500 board. - You can say 'Y' to both this and the USER flash option, to use - both banks. - -config MTD_PB1500_USER - bool "Pb1100/Pb1500 User Flash device (2nd 32MB bank)" - depends on MIPS && (MTD_PB1500 || MTD_PB1100) - help - Use the second of the two 32MB flash banks on Pb1100/Pb1500 board. - You can say 'Y' to both this and the BOOT flash option, to use - both banks. - -config MTD_DB1X00 - tristate "Db1X00 Flash device" - depends on MIPS && (MIPS_DB1000 || MIPS_DB1100 || MIPS_DB1500) - help - Flash memory access on Alchemy Db1X00 Boards - -config MTD_DB1X00_BOOT - bool "Db1X00 Boot Flash device" - depends on MIPS && MTD_DB1X00 - help - Use the first of the two 32MB flash banks on Db1X00 board. - You can say 'Y' to both this and the USER flash option, to use - both banks. - -config MTD_DB1X00_USER - bool "Db1X00 User Flash device (2nd 32MB bank)" - depends on MIPS && MTD_DB1X00 - help - Use the second of the two 32MB flash banks on Db1X00 boards. - You can say 'Y' to both this and the BOOT flash option, to use - both banks. - -config MTD_BOSPORUS - tristate "Bosporus Flash device" - depends on MIPS && MIPS_BOSPORUS +config MTD_ALCHEMY + tristate ' AMD Alchemy Pb1xxx/Db1xxx/RDK MTD support' + depends on MIPS && SOC_AU1X00 help - Flash memory access on Alchemy Bosporus Board + Flash memory access on AMD Alchemy Pb/Db/RDK Reference Boards config MTD_XXS1500 tristate "MyCable XXS1500 Flash device" diff -Naur --exclude=CVS linux-2.6-orig/drivers/mtd/maps/Makefile linux-2.6-dev/drivers/mtd/maps/Makefile --- linux-2.6-orig/drivers/mtd/maps/Makefile 2005-01-17 21:23:31.000000000 -0800 +++ linux-2.6-dev/drivers/mtd/maps/Makefile 2005-02-21 21:17:59.000000000 -0800 @@ -69,7 +69,4 @@ obj-$(CONFIG_MTD_IXP2000) += ixp2000.o obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o obj-$(CONFIG_MTD_DMV182) += dmv182.o -obj-$(CONFIG_MTD_PB1000) += pb1xxx-flash.o -obj-$(CONFIG_MTD_PB1100) += pb1xxx-flash.o -obj-$(CONFIG_MTD_PB1500) += pb1xxx-flash.o -obj-$(CONFIG_MTD_DB1X00) += db1x00-flash.o +obj-$(CONFIG_MTD_ALCHEMY) += alchemy-flash.o --------------040808010503020405080103-- From ibrahim@schenk.isar.de Tue Feb 22 08:34:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 08:34:50 +0000 (GMT) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:23637 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Tue, 22 Feb 2005 08:34:34 +0000 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1M8XrH26414; Tue, 22 Feb 2005 09:33:53 +0100 Received: from [172.22.10.24] (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j1M8Xqc19910; Tue, 22 Feb 2005 09:33:53 +0100 Message-ID: <421AEE70.6060108@schenk.isar.de> Date: Tue, 22 Feb 2005 09:33:52 +0100 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Sandiford CC: linux-mips@linux-mips.org Subject: Re: [PATCH] SMP/TLB problems with 64-bit kernels References: <87r7jbdnba.fsf@firetop.home> In-Reply-To: <87r7jbdnba.fsf@firetop.home> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 7305 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: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Content-Length: 483 Lines: 20 Richard Sandiford wrote: > A 64-bit SB1 SMP kernel built from current 2.6 CVS sources will > hang when trying to run init. This is probably the same as the > bug reported here: > > http://www.linux-mips.org/archives/linux-mips/2005-01/msg00086.html > It is indeed. > Please apply if OK. > I second that. I have tested the patch on my Yosemite board and it makes a 64-bit SMP kernel work again (as long as I do not have more than 512 MB of memory). Thanks Rojhalat Ibrahim From Rishabh@soc-soft.com Tue Feb 22 09:00:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 09:00:20 +0000 (GMT) Received: from mail.soc-soft.com ([IPv6:::ffff:202.56.254.199]:20744 "EHLO IGateway.soc-soft.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 22 Feb 2005 09:00:04 +0000 Received: from mail.soc-soft.com ([192.168.4.25]) by IGateway with trend_isnt_name_B; Tue, 22 Feb 2005 14:31:16 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: HIGHMEM Query Date: Tue, 22 Feb 2005 14:31:16 +0530 Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C571A8D@soc-mail.soc-soft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIGHMEM Query Thread-Index: AcUVMY9Rfs9oZxXiRQ2woJI9KLLRqwDiuvlA From: To: Cc: 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: 7306 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: 3575 Lines: 94 hi ralf, Thanks for the valuable input, I checked the TLB Entry and found Value in EntryLo0/1 seems absurd. Can you suggest me some way about how to approach this problem? ________________________________________________________________________ ___ xdr_partial_copy_from_skb: kaddr: ffffd000, ppage: 83f751a0, *ppage: 8117ff90 Data bus error, epc == 80161a90, ra == 80161924 ENTRYHI: 0xFFFFC000, ENTRYLO0:0x00000001, ENTRYLO1:0x001FFF5F INDEX: 0x00000009 Oops in traps.c::do_be, line 465: $0 : 00000000 10008400 ffffd000 00000000 ffffd000 83f730a0 00000978 00000000 $8 : 622f2123 732f6e69 0a230a68 74532023 20747261 ffffffff 00000010 756e694c $16: 83f730a0 ffffd000 00000998 000020a4 0000006c 00000000 ffffd000 811e3cc0 $24: 00000018 801e95ff 811e2000 811e3bc0 00000000 80161924 Hi : 00000000 Lo : 00000001 epc : 80161a90 Not tainted Status: 10008403 Cause : 0000001c Process ksoftirqd_CPU0 (pid: 3, stackpage=811e2000) Stack: 0000003c 0000003e 80036a40 80036ae4 00000998 00000998 811e3cc0 00000a04 8010813c 80036ae4 0000004c 80155f58 10008401 ffffc000 0000000a 0000003c 0000004e 80155f58 80037048 10008401 00000000 83f751a0 0000006c 00000998 811e3cc0 83f751a0 00001000 80212ff0 83fcc0b4 811e3cc0 80155f58 80155fa0 83fcd080 80212ff0 ffffd000 00001000 00000000 83f751a0 ffffd000 00001000 ... Call Trace: [<80036a40>] [<80036ae4>] [<8010813c>] [<80036ae4>] [<80155f58>] [<80155f58>] [<80037048>] [<80155f58>] [<80155fa0>] [<80160794>] [<8011d68c>] [<801560a8>] [<80185c7f>] [<80156288>] [<8015627c>] [<80140748>] [<80140738>] [<80156164>] [<80140d0c>] [<80140d00>] [<80036e50>] [<80181ff8>] [<80106420>] [<8011d898>] [<80140b04>] [<80114414>] [<8011d68c>] [<8011ec50>] [<8011d8bc>] [<8011d3a0>] [<8011d37c>] [<8011d68c>] [<8011db0c>] [<8011d318>] [<80114414>] [<8011d8bc>] [<8011d628>] [<8011d604>] [<8011d8bc>] [<8010b9c4>] ... Code: 8cac0010 8caf0014 ac880000 8ca80018 8ca9001c 24a50020 2484 0020 ac8affe8 ________________________________________________________________________ ___ -----Original Message----- From: Ralf Baechle [mailto:ralf@linux-mips.org] Sent: Friday, February 18, 2005 2:07 AM To: Rishabh Kumar Goel Cc: linux-mips@linux-mips.org; mel@skynet.ie; jbglaw@lug-owl.de Subject: Re: HIGHMEM Query On Thu, Feb 17, 2005 at 10:40:22AM +0530, Rishabh@soc-soft.com wrote: First, fix your mailer setup, it's littering emails with extra carriage returns. > I have been working on HIGHMEM fixation for 2.4.20 linux MVL kernel for > MIPS architecture. > I am getting DATA BUS ERROR(ADDR: 0xffffd000) exception when loading > (copying the data received from ethernet to the kernel space in FIXADDR > SPACE) "/sbin/init" from TARGET ROOT DIR (through NFS). I figured out > that this is because there is no corresponding page table entry for the > same. That does not make sense. If you don't have a pagetable entry the CPU will take a TLB reload exception. If the entry is invalid, the kernel will die with an oops. A bus error has different causes. Ralf 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 ralf@linux-mips.org Tue Feb 22 13:18:42 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 13:18:57 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:56590 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 22 Feb 2005 13:18:42 +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 j1MDCNQB001320; Tue, 22 Feb 2005 13:12:32 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1MB0GXW026910; Tue, 22 Feb 2005 11:00:16 GMT Date: Tue, 22 Feb 2005 11:00:16 +0000 From: Ralf Baechle To: Rishabh@soc-soft.com Cc: linux-mips@linux-mips.org Subject: Re: HIGHMEM Query Message-ID: <20050222110016.GA26269@linux-mips.org> References: <4BF47D56A0DD2346A1B8D622C5C5902C571A8D@soc-mail.soc-soft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C571A8D@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: 7307 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: 297 Lines: 10 On Tue, Feb 22, 2005 at 02:31:16PM +0530, Rishabh@soc-soft.com wrote: > Thanks for the valuable input, I checked the TLB Entry and found > > Value in EntryLo0/1 seems absurd. Can you suggest me some way about how > to approach this problem? An undecoded oops message is useless, sorry. Ralf From eckhardt@satorlaser.com Tue Feb 22 15:30:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 15:30:24 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.184]:45012 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Tue, 22 Feb 2005 15:30:08 +0000 Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D3bzD-0002yf-00 for linux-mips@linux-mips.org; Tue, 22 Feb 2005 16:30:07 +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 1D3bzD-0002Lm-00 for linux-mips@linux-mips.org; Tue, 22 Feb 2005 16:30:07 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: Fixes to MTD flash driver on AMD Alchemy db1100 board Date: Tue, 22 Feb 2005 16:32:53 +0100 User-Agent: KMail/1.7.1 References: <1108962105.6611.24.camel@SillyPuddy.localdomain> <1109052412.20045.6.camel@SillyPuddy.localdomain> <421ADE76.5020905@embeddedalley.com> In-Reply-To: <421ADE76.5020905@embeddedalley.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502221632.53448.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: 7308 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: 1249 Lines: 39 Pete Popov wrote: > Here is a 2.6 patch that gets rid of all the Au1x mapping files and > replaces them with a single file. Big step forward, this looks much cleaner and easier to maintain! Just a few nits: 1. mymtd = do_map_probe("cfi_probe", &alchemy_map); Doesn't this mean that the Alchemy flash driver depends on the CFI interface? I also see that CONFIG_MTD_CFI is not set in the configfiles for some boards. 2. If above do_map_probe() returns NULL, the ioremap()ed memory is leaked. Doesn't matter that much probably, but is trivial to fix. if (!mymtd) { iounmap( alchemy_map.virt); return -ENXIO; } 3. No need to cast the parameter to iounmap(), it should happily digest whatever ioremap() returns. If that gives warnings, something different is going wrong in between. ;) I finally figured out that my board is based largely on db1100, but the on-board flash in particular isn't, it's just one 16MBit chip on board. Also, the access width is 16 bit and not 32. Seems like I'm going to introduce another board type TTP1100... One more question on the partition layout: is this a real hardware property or is this just convention? Can't I configure the flash as I want to? I'm making progress, thank you all! Uli From guy.streeter@gmail.com Tue Feb 22 17:45:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 17:46:02 +0000 (GMT) Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.192]:18180 "EHLO rproxy.gmail.com") by linux-mips.org with ESMTP id ; Tue, 22 Feb 2005 17:45:46 +0000 Received: by rproxy.gmail.com with SMTP id 40so625989rnz for ; Tue, 22 Feb 2005 09:45:45 -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=hkkpkYXcVLO0fG03/RMAjS8w9DOY+uqvNX9qKbTRkife34Q8aILCL6risvzhEANnF3k/HBemqGjsvG59rmA5W68F0QTi2llzpw9B9lMUmPLuDLwlAzinOd8T/ZqWSSC6/S6HVRBHZXjiOS7AzFQT0+mfpkmmaMr6QxcBqrHsA+s= Received: by 10.38.179.14 with SMTP id b14mr186309rnf; Tue, 22 Feb 2005 09:45:44 -0800 (PST) Received: by 10.38.179.17 with HTTP; Tue, 22 Feb 2005 09:45:44 -0800 (PST) Message-ID: <52dd176405022209452e21643@mail.gmail.com> Date: Tue, 22 Feb 2005 11:45:44 -0600 From: Guy Streeter Reply-To: Guy Streeter To: linux-mips Subject: on-board USB on malta 4kc and a 2.6 kernel? 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: 7309 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: guy.streeter@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1399 Lines: 39 I am trying to verify that on-board USB should work on a malta 4kc board. There appears to me to be some conflict between it and the serial ports. I've been asking around and nobody says they have done it, so I'd like to hear from anyone who has. Here's what I see: Using the mips.org CVS HEAD kernel source, and any USB device plugged in, during bootup there is garbaged output on the console as USB starts up: ============================== drivers/usb/input/hid-core.c: v2.0:USB HID core driver NE Risr otolamynghch dde IPrtg chha blof1buet 4yt N: gied otolamyblhe 96i 4628yt) NE Rier otofaly7 N: gied ocofaly5eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 input: USB HID v1.10 Keyboard [Microsoft Natural Keyboard Pro] on usb-0000:00:0a.2-2.1 input: USB HID v1.10 Device [Microsoft Natural Keyboard Pro] on usb-0000:00:0a.2-2.1 ============================== Once the serial console gets to a login: prompt, the first character I type is interpreted as a sysrq key. If I run "lsusb -v" I will start seeing: usb 1-2: lsusb timed out on ep0in usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 256 ret -145 The console will again interpret a character as a sysrq key, and the Ethernet controller starts timing out. Does this look familiar to anyone? Has anyone successfully used the on-boards USB on a malta 4kc board? thanks for your help, --Guy Streeter From bbreuer@righthandtech.com Tue Feb 22 22:20:57 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Feb 2005 22:21:12 +0000 (GMT) Received: from mail2.dataflo.net ([IPv6:::ffff:207.252.248.127]:56847 "EHLO mail2.dataflo.net") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Tue, 22 Feb 2005 22:20:57 +0000 Received: (qmail 66210 invoked by uid 1009); 22 Feb 2005 16:20:54 -0600 Received: from elk-righthand-router.dataflo.net (HELO server1.RightHand.righthandtech.com) (207.252.249.22) by mail2.dataflo.net with SMTP; 22 Feb 2005 16:20:54 -0600 content-class: urn:content-classes:message Subject: RE: swapon failure with au1550 Date: Tue, 22 Feb 2005 16:20:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: swapon failure with au1550 Thread-Index: AcUZLLaERrIB9opzSlWlu0VPWdsF7g== From: "Bob Breuer" 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: 7310 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: bbreuer@righthandtech.com Precedence: bulk X-list: linux-mips Content-Length: 509 Lines: 13 The bitmask in a pte for swap type is 0x0000_1f00. In the CPU_MIPS32 && 64BIT_PHYS_ADDR case, _PAGE_FILE is 0x0000_0400. Since _PAGE_FILE is set in the maxed out swap type, it triggers a BUG(). If I move the swap type field like this: #define __swp_type(x) (((x).val >> 2) & 0x0f) then it works for me. This makes use of the _PAGE_DIRTY and _CACHE_MASK bits which were being used in the !64BIT_PHYS_ADDR case. Is this a reasonable solution, or should a different grouping of bits be used? Bob Breuer From maillist@jg555.com Wed Feb 23 00:33:12 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 00:33:28 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:36526 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 00:33:12 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN jim, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 22 Feb 2005 16:33:10 -0800 id 00008479.421BCF46.00000289 Message-ID: <421BCF34.90308@jg555.com> Date: Tue, 22 Feb 2005 16:32:52 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Building GLIBC 2.3.4 on MIPS 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: 7311 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: 1140 Lines: 29 I'm trying to build the current glibc with my RaQ2, everything builds ok, until I start compiling strace. syscall.c: In function `dumpio': syscall.c:449: error: `SYS_read' undeclared (first use in this function) syscall.c:449: error: (Each undeclared identifier is reported only once syscall.c:449: error: for each function it appears in.) syscall.c:465: error: `SYS_write' undeclared (first use in this function) syscall.c: In function `syscall_fixup': syscall.c:1265: warning: unused variable `pid' syscall.c: In function `trace_syscall': syscall.c:2481: error: `SYS_exit' undeclared (first use in this function) make[1]: *** [syscall.o] Error 1 make[1]: Leaving directory `/usr/src/strace-4.5.9' make: *** [all] Error 2 Which leads me to check syscall.h, then I noticed a big difference from my x86 version to this version, all the SYS_ entries are missing. Did I build it wrong or is this a glibc issue, due to the addition of the mips32 and mips64 directories. Here is my bug report with the glibc folks for everyone's reference. http://sources.redhat.com/bugzilla/show_bug.cgi?id=758 -- ---- Jim Gifford maillist@jg555.com From jgreen@users.sourceforge.net Wed Feb 23 00:42:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 00:42:40 +0000 (GMT) Received: from mail-relay.infostations.net ([IPv6:::ffff:69.19.152.5]:40425 "EHLO mail-relay.infostations.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 00:42:24 +0000 Received: from seriyu.infostations.net (seriyu.infostations.net [71.4.40.35]) by mail-relay.infostations.net (Postfix) with ESMTP id 3AFF79F822 for ; Tue, 22 Feb 2005 16:42:24 -0800 (PST) Received: from host-69-19-148-86.rev.o1.com ([69.19.148.86]) by seriyu.infostations.net with esmtp (Exim 4.41 #1) id 1D3kbb-0000Uz-VF for ; Tue, 22 Feb 2005 16:42:21 -0800 From: Josh Green To: mips-linux@mips-linux.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lmo4fQnamer33EKbJefb" Message-Id: <1109119128.27702.12.camel@SillyPuddy.localdomain> Mime-Version: 1.0 Subject: Memory allocation problem with iptables and NAT Resent-From: Josh Green Resent-To: linux-mips@linux-mips.org Date: Tue, 22 Feb 2005 16:43:56 -0800 X-Mailer: Evolution 2.0.2 Resent-Message-Id: <20050223004224.3AFF79F822@mail-relay.infostations.net> Resent-Date: Tue, 22 Feb 2005 16:42:24 -0800 (PST) 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: 7312 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 Content-Length: 4802 Lines: 99 --=-lmo4fQnamer33EKbJefb Content-Type: multipart/mixed; boundary="=-556lHh5vBz+RX6GxOpWX" --=-556lHh5vBz+RX6GxOpWX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm not yet sure if this is a problem with the Linux MIPS platform in particular, but I thought I would probe to see if anyone else has experienced this. I'm using an AMD Alchemy db1100 board with a CVS checkout from a few weeks back of the mips-linux kernel (2.6.11 rc2). I can insert the ip_tables and iptable_nat modules fine. But the following iptables command fails: # 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. I did an strace and came up with the attached output. Of particular interest is this call: old_mmap(NULL, 1651212288, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, 0, 0) =3D -1 ENOMEM (Cannot allocate memory) Wow, seems something is trying to mmap over 1.6GB of data. If anyone has any tips on why this is happening I would appreciate the input. Best regards, Josh Green --=-556lHh5vBz+RX6GxOpWX Content-Disposition: attachment; filename=iptables_strace.txt Content-Type: text/plain; name=iptables_strace.txt; charset=ISO-8859-1 Content-Transfer-Encoding: base64 IyBzdHJhY2UgaXB0YWJsZXMgLXQgbmF0IC1GDQpleGVjdmUoIi91c3Ivc2Jpbi9pcHRhYmxlcyIs IFsiaXB0YWJsZXMiLCAiLXQiLCAibmF0IiwgIi1GIl0sIFsvKiAxNiB2YXJzICovXSkgPSAwDQpp b2N0bCgwLCBUSU9DTlhDTCwge0IxMTUyMDAgb3Bvc3QgaXNpZyBpY2Fub24gLWVjaG8gLi4ufSkg PSAwDQppb2N0bCgxLCBUSU9DTlhDTCwge0IxMTUyMDAgb3Bvc3QgaXNpZyBpY2Fub24gLWVjaG8g Li4ufSkgPSAwDQpzb2NrZXQoUEZfSU5FVCwgU09DS19SQVcsIElQUFJPVE9fUkFXKSAgPSA0DQpn ZXRzb2Nrb3B0KDQsIFNPTF9JUCwgMHg0MCAvKiBJUF8/Pz8gKi8sICJuYXRcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgWzg0XSkgPSAwDQpi cmsoMCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDEwMDA3MDAwDQpicmso MHgxMDAwODAwMCkgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDEwMDA4MDAwDQpvbGRfbW1h cChOVUxMLCAxNjUxMjEyMjg4LCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQ X0FOT05ZTU9VUywgMCwgMCkgPSAtMSBFTk9NRU0gKENhbm5vdCBhbGxvY2F0ZSBtZW1vcnkpDQpi cmsoMHg3MjZiZjAwMCkgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDEwMDA4MDAwDQpvbGRf bW1hcChOVUxMLCAxNjUxMjEyMjg4LCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8 TUFQX0FOT05ZTU9VUywgMCwgMCkgPSAtMSBFTk9NRU0gKENhbm5vdCBhbGxvY2F0ZSBtZW1vcnkp DQpjbG9zZSg0KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwDQpvcGVuKCIvcHJv Yy9zeXMva2VybmVsL21vZHByb2JlIiwgT19SRE9OTFkpID0gNA0KcmVhZCg0LCAiL3NiaW4vbW9k cHJvYmVcbiIsIDEwMjQpICAgICAgID0gMTUNCmNsb3NlKDQpICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA9IDANCmZvcmsoKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9 IDEwNDENCndhaXQ0KC0xLCBbV0lGRVhJVEVEKHMpICYmIFdFWElUU1RBVFVTKHMpID09IDBdLCAw LCBOVUxMKSA9IDEwNDENCi0tLSBTSUdDSExEIChDaGlsZCBleGl0ZWQpIEAgMCAoMCkgLS0tDQpz b2NrZXQoUEZfSU5FVCwgU09DS19SQVcsIElQUFJPVE9fUkFXKSAgPSA0DQpnZXRzb2Nrb3B0KDQs IFNPTF9JUCwgMHg0MCAvKiBJUF8/Pz8gKi8sICJuYXRcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwzNDBcMjU2XDBcMjBcMFwwXDBcMFwzMFw0Ii4uLiwgWzg0XSkgPSAwDQpvbGRfbW1hcChOVUxM LCAxNjUxMjEyMjg4LCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05Z TU9VUywgMCwgMCkgPSAtMSBFTk9NRU0gKENhbm5vdCBhbGxvY2F0ZSBtZW1vcnkpDQpicmsoMHg3 MjZiZjAwMCkgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDEwMDA4MDAwDQpvbGRfbW1hcChO VUxMLCAxNjUxMjEyMjg4LCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FO T05ZTU9VUywgMCwgMCkgPSAtMSBFTk9NRU0gKENhbm5vdCBhbGxvY2F0ZSBtZW1vcnkpDQpjbG9z ZSg0KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwDQp3cml0ZSgyLCAiaXB0YWJs ZXMiLCA4aXB0YWJsZXMpICAgICAgICAgICAgICAgICA9IDgNCndyaXRlKDIsICIgdiIsIDIgdikg ICAgICAgICAgICAgICAgICAgICAgID0gMg0Kd3JpdGUoMiwgIjEuMy4wIiwgNTEuMy4wKSAgICAg ICAgICAgICAgICAgICAgPSA1DQp3cml0ZSgyLCAiOiAiLCAyOiApICAgICAgICAgICAgICAgICAg ICAgICA9IDINCndyaXRlKDIsICJjYW5cJ3QgaW5pdGlhbGl6ZSBpcHRhYmxlcyB0YWJsZSAiLi4u LCAzM2Nhbid0IGluaXRpYWxpemUgaXB0YWJsZXMgdGFibGUgYCkgPSAzMw0Kd3JpdGUoMiwgIm5h dCIsIDNuYXQpICAgICAgICAgICAgICAgICAgICAgID0gMw0Kd3JpdGUoMiwgIlwnOiAiLCAzJzog KSAgICAgICAgICAgICAgICAgICAgID0gMw0Kd3JpdGUoMiwgIk1lbW9yeSBhbGxvY2F0aW9uIHBy b2JsZW0iLCAyNU1lbW9yeSBhbGxvY2F0aW9uIHByb2JsZW0pID0gMjUNCndyaXRlKDIsICJcbiIs IDENCikgICAgICAgICAgICAgICAgICAgICAgID0gMQ0Kd3JpdGUoMiwgIlBlcmhhcHMgaXB0YWJs ZXMgb3IgeW91ciBrZXJuZWwgIi4uLiwgNTRQZXJoYXBzIGlwdGFibGVzIG9yIHlvdXIga2VybmVs IG5lZWRzIHRvIGJlIHVwZ3JhZGVkLg0KKSA9IDU0DQpleGl0KDMpICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPSA/DQo= --=-556lHh5vBz+RX6GxOpWX-- --=-lmo4fQnamer33EKbJefb 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) iD8DBQBCG9CXRoMuWKCcbgQRAuIEAJsEbq3+Uw+XfX4s8t75i2ZiwC7t8gCfbAUW ErKfR8aDZAk2YL9a7K1UVbQ= =bqul -----END PGP SIGNATURE----- --=-lmo4fQnamer33EKbJefb-- From kumba@gentoo.org Wed Feb 23 00:54:45 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 00:55:00 +0000 (GMT) Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:38072 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 00:54:45 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (sccrmhc11) with ESMTP id <2005022300543801100t35ete>; Wed, 23 Feb 2005 00:54:39 +0000 Message-ID: <421BD427.5000902@gentoo.org> Date: Tue, 22 Feb 2005 19:53:59 -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@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS References: <421BCF34.90308@jg555.com> In-Reply-To: <421BCF34.90308@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: 7313 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: 1883 Lines: 43 Jim Gifford wrote: > I'm trying to build the current glibc with my RaQ2, everything builds > ok, until I start compiling strace. > > syscall.c: In function `dumpio': > syscall.c:449: error: `SYS_read' undeclared (first use in this function) > syscall.c:449: error: (Each undeclared identifier is reported only once > syscall.c:449: error: for each function it appears in.) > syscall.c:465: error: `SYS_write' undeclared (first use in this function) > syscall.c: In function `syscall_fixup': > syscall.c:1265: warning: unused variable `pid' > syscall.c: In function `trace_syscall': > syscall.c:2481: error: `SYS_exit' undeclared (first use in this function) > make[1]: *** [syscall.o] Error 1 > make[1]: Leaving directory `/usr/src/strace-4.5.9' > make: *** [all] Error 2 > > Which leads me to check syscall.h, then I noticed a big difference from > my x86 version to this version, all the SYS_ entries are missing. Did I > build it wrong or is this a glibc issue, due to the addition of the > mips32 and mips64 directories. > > Here is my bug report with the glibc folks for everyone's reference. > http://sources.redhat.com/bugzilla/show_bug.cgi?id=758 We've bumped into this on the gentoo-side of things. The fix we're using (for now) is this a modified version of this patch here: http://lists.debian.org/debian-mips/2004/01/msg00036.html The above patch wasn't intended for 2.3.4 by default I believe, so it doesn't apply cleanly. It had to be re-diffed for 2.3.4. You can find this version here: http://dev.gentoo.org/~kumba/tmp/6630_mips_fix-syscall_h-again.patch The resulting bits/syscall.h isn't the cleanest thing, but strace will build against it and it does appear to work. --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 Wed Feb 23 01:02:20 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 01:02:35 +0000 (GMT) Received: from adsl-67-116-42-149.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.149]:5975 "EHLO avtrex.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 01:02:20 +0000 Received: from [192.168.0.35] ([192.168.0.35] unverified) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Feb 2005 17:02:17 -0800 Message-ID: <421BD616.4030101@avtrex.com> Date: Tue, 22 Feb 2005 17:02:14 -0800 From: David Daney User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Gifford CC: linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS References: <421BCF34.90308@jg555.com> In-Reply-To: <421BCF34.90308@jg555.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 01:02:17.0733 (UTC) FILETIME=[51E40B50:01C51943] 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: 7314 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: 1747 Lines: 56 Jim Gifford wrote: > I'm trying to build the current glibc with my RaQ2, everything builds > ok, until I start compiling strace. > > syscall.c: In function `dumpio': > syscall.c:449: error: `SYS_read' undeclared (first use in this function) > syscall.c:449: error: (Each undeclared identifier is reported only once > syscall.c:449: error: for each function it appears in.) > syscall.c:465: error: `SYS_write' undeclared (first use in this function) > syscall.c: In function `syscall_fixup': > syscall.c:1265: warning: unused variable `pid' > syscall.c: In function `trace_syscall': > syscall.c:2481: error: `SYS_exit' undeclared (first use in this function) > make[1]: *** [syscall.o] Error 1 > make[1]: Leaving directory `/usr/src/strace-4.5.9' > make: *** [all] Error 2 > > Which leads me to check syscall.h, then I noticed a big difference from > my x86 version to this version, all the SYS_ entries are missing. Did I > build it wrong or is this a glibc issue, due to the addition of the > mips32 and mips64 directories. > > Here is my bug report with the glibc folks for everyone's reference. > http://sources.redhat.com/bugzilla/show_bug.cgi?id=758 > It seems that you might need some (but not all) of the patch I posted here: http://www.linux-mips.org/archives/linux-mips/2004-10/msg00068.html Specifically I think you will need at least the parts that add #include To many of the .h files. Basically any file that uses the symbol _MIPS_SIM and friends needs to either directly or indirectly include sgidefs.h You may also need: http://www.linux-mips.org/archives/linux-mips/2004-10/msg00142.html And something like this: http://sources.redhat.com/ml/libc-alpha/2004-11/msg00165.html David Daney. From maillist@jg555.com Wed Feb 23 02:42:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 02:42:33 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:37554 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 02:42:19 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN jim, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Tue, 22 Feb 2005 18:42:17 -0800 id 00008476.421BED89.00001DD2 Message-ID: <421BED79.2010305@jg555.com> Date: Tue, 22 Feb 2005 18:42:01 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Daney CC: linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> In-Reply-To: <421BD616.4030101@avtrex.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: 7315 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: 541 Lines: 18 Thanx Kumba and David I really appreciate the help. Got one other question for you, this was brought up on my LFS for the RaQ2. http://sources.redhat.com/ml/libc-alpha/2005-01/msg00063.html Here is the message for those who don't want to link. A user attempting to build glibc kept getting "getconf" missing errors, upon checking /usr/bin/getconf, he found the getconf was a directory with 2 files in it POSIX_V6_ILP32_OFFBIG POSIX_V6_ILP32_OFF32 Now, I've been able to recreate this issue, but haven't figured out the root cause. From eckhardt@satorlaser.com Wed Feb 23 08:45:05 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 08:46:03 +0000 (GMT) Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.184]:52426 "EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 08:45:05 +0000 Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D3s8k-0004Gq-00 for linux-mips@linux-mips.org; Wed, 23 Feb 2005 09:45:02 +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 1D3s8k-0007T7-00 for linux-mips@linux-mips.org; Wed, 23 Feb 2005 09:45:02 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: [patch] generate error when trying to compile PCMCIA driver without 64 bit addresses Date: Wed, 23 Feb 2005 09:47:53 +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: <200502230947.53588.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: 7316 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: 1143 Lines: 32 Greetings! PCMCIA controller registers are mapped in an area that requires the upper four of the 36 bit addresses, so this can't work without 64 bit physical address support. Sick thing is that due to some stupid casts the whole thing compiles without warnings even without 64 bit support but of course doesn't run. However, that's a topic for a different patch. Uli Changes: * generate error when compiled without 64bit physical address support --- Index: drivers/pcmcia/au1000_generic.h =================================================================== RCS file: /home/cvs/linux/drivers/pcmcia/au1000_generic.h,v retrieving revision 1.4 diff -u -r1.4 au1000_generic.h --- drivers/pcmcia/au1000_generic.h 19 Oct 2004 07:26:37 -0000 1.4 +++ drivers/pcmcia/au1000_generic.h 23 Feb 2005 08:40:05 -0000 @@ -30,6 +30,10 @@ #include #include "cs_internal.h" +#if !defined(CONFIG_64BIT_PHYS_ADDR) +# error "need 64bit physical address support to access PCMCIA controller" +#endif + #define AU1000_PCMCIA_POLL_PERIOD (2*HZ) #define AU1000_PCMCIA_IO_SPEED (255) #define AU1000_PCMCIA_MEM_SPEED (300) From jpfoster@exterity.co.uk Wed Feb 23 11:22:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 11:22:49 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:44956 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 11:22:27 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 11:23:40 +0000 Subject: Big Endian au1550 From: JP Foster To: linux-mips@linux-mips.org Content-Type: text/plain Date: Wed, 23 Feb 2005 11:22:16 +0000 Message-Id: <1109157737.16445.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 11:23:40.0828 (UTC) FILETIME=[2058DDC0:01C5199A] 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: 7317 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: 2306 Lines: 68 Hi all, In the linux-mips cvs big endian operation of the au1550 is not selectable. Is there a reason for this? what would I need to do to get big endian support? The chip does run big endian, as I have yamon running on it here. And a previously the linux-mips kernel allowed this. The kernel will compile big end but I get an oops as the kernel starts up Thanks JP VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Break instruction in kernel code in arch/mips/kernel/traps.c::do_bp, line 557[#1]: Cpu 0 $ 0 : 00000000 1000fc00 00000000 10000000 $ 4 : 00000001 00000001 fffb6ccf 00000000 $ 8 : 10000000 00000008 803c0000 00100100 $12 : 811c5edd fffffffa ffffffff 0000000a $16 : 1000fc01 803e7bc0 803c0000 80380000 $20 : 803d0000 80380000 803d0000 00000000 $24 : 00000008 811c5df9 $28 : 811c4000 811c5e40 811c5e40 80103900 Hi : 00000000 Lo : 00000000 epc : 8033f818 preempt_schedule_irq+0xcc/0xd8 Not tainted ra : 80103900 ret_from_fork+0x0/0x8 Status: 1000fc02 KERNEL EXL Cause : 00800024 PrId : 03030200 Modules linked in: Process swapper (pid: 1, threadinfo=811c4000, task=803e7bc0) Stack : 803fbbf4 803fbbe0 1000fc01 8012f7b8 1000fc01 80379420 803c0000 00000000 80103900 80100c00 811c5ed8 00000000 00000000 80247490 803fbb80 813b396c 00000000 1000fc00 00000001 811c4008 00000001 00000001 803c0028 0000000b 002d4cae 801fc8ec 00000018 00100100 811c5edd fffffffa ffffffff 0000000a 1000fc01 80379420 803c0000 80380000 803d0000 80380000 803d0000 00000000 ... Call Trace: [<8012f7b8>] irq_exit+0x4c/0x5c [<80103900>] ret_from_fork+0x0/0x8 [<80100c00>] au1000_IRQ+0x120/0x1a0 [<80247490>] class_device_create_file+0x20/0x34 [<801fc8ec>] memset_partial+0x30/0x6c [<8012f9c8>] __tasklet_schedule+0xb8/0xec [<8012f9e0>] __tasklet_schedule+0xd0/0xec [<803b3ffc>] kbd_init+0x184/0x22c [<80210480>] alloc_tty_driver+0x24/0x64 [<80247fc4>] class_simple_device_add+0xe0/0x178 [<803b4484>] vty_init+0xf8/0x128 [<803b3784>] tty_init+0x1d0/0x1fc [<803b3428>] rand_initialize+0x128/0x1f0 [<803b33f0>] rand_initialize+0xf0/0x1f0 [<803b1c50>] init_iso9660_fs+0x60/0x9c [<80100508>] init+0x9c/0x274 [<8010541c>] kernel_thread_helper+0x10/0x18 [<8010540c>] kernel_thread_helper+0x0/0x18 From ralf@linux-mips.org Wed Feb 23 11:25:31 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 11:25:46 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:12306 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 11:25:31 +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 j1NBJI9g008085; Wed, 23 Feb 2005 11:19:18 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1NBJIna008084; Wed, 23 Feb 2005 11:19:18 GMT Date: Wed, 23 Feb 2005 11:19:18 +0000 From: Ralf Baechle To: Ulrich Eckhardt Cc: linux-mips@linux-mips.org Subject: Re: [patch] generate error when trying to compile PCMCIA driver without 64 bit addresses Message-ID: <20050223111918.GC6327@linux-mips.org> References: <200502230947.53588.eckhardt@satorlaser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502230947.53588.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: 7318 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: 890 Lines: 24 On Wed, Feb 23, 2005 at 09:47:53AM +0100, Ulrich Eckhardt wrote: > PCMCIA controller registers are mapped in an area that requires the upper four > of the 36 bit addresses, so this can't work without 64 bit physical address > support. Sick thing is that due to some stupid casts the whole thing compiles > without warnings even without 64 bit support but of course doesn't run. > However, that's a topic for a different patch. > +#if !defined(CONFIG_64BIT_PHYS_ADDR) > +# error "need 64bit physical address support to access PCMCIA controller" > +#endif > + > #define AU1000_PCMCIA_POLL_PERIOD (2*HZ) > #define AU1000_PCMCIA_IO_SPEED (255) > #define AU1000_PCMCIA_MEM_SPEED (300) No. In drivers/pcmcia/Kconfig do something like: config PCMCIA_AU1X00 tristate "Au1x00 pcmcia support" select 64BIT_PHYS_ADDR depends on SOC_AU1X00 && PCMCIA Ralf From ralf@linux-mips.org Wed Feb 23 11:30:55 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 11:31:09 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:36118 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 11:30:55 +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 j1NBNe6B008282; Wed, 23 Feb 2005 11:23:40 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1NBNd18008281; Wed, 23 Feb 2005 11:23:39 GMT Date: Wed, 23 Feb 2005 11:23:39 +0000 From: Ralf Baechle To: JP Foster Cc: linux-mips@linux-mips.org Subject: Re: Big Endian au1550 Message-ID: <20050223112339.GD6327@linux-mips.org> References: <1109157737.16445.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109157737.16445.6.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: 7319 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: 929 Lines: 22 On Wed, Feb 23, 2005 at 11:22:16AM +0000, JP Foster wrote: > Hi all, > In the linux-mips cvs big endian operation of the au1550 is not > selectable. Is there a reason for this? > what would I need to do to get big endian support? > > The chip does run big endian, as I have yamon running on it here. > And a previously the linux-mips kernel allowed this. > The kernel will compile big end but I get an oops as the kernel > starts up I recently rewrote the endianes selection in the Kconfig menus. The individual platforms will now have to explicitly select SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate which endianess they support. I know that Alchemy supports big endian operation in hardware but no idea if all the Linux code is working properly, so I've been conservative and choose to limit the system to little endian until somebody reports big endianess support to be actually working. Ralf From ralf@linux-mips.org Wed Feb 23 11:45:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 11:45:19 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:24328 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 11:45: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 j1NBcHiv008981; Wed, 23 Feb 2005 11:38:17 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1NBcG1s008980; Wed, 23 Feb 2005 11:38:16 GMT Date: Wed, 23 Feb 2005 11:38:16 +0000 From: Ralf Baechle To: David Daney Cc: Jim Gifford , linux-mips@linux-mips.org Subject: Referencing the online list archive, was Re: Building GLIBC 2.3.4 on MIPS Message-ID: <20050223113816.GA8369@linux-mips.org> References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421BD616.4030101@avtrex.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: 7320 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: 545 Lines: 12 On Tue, Feb 22, 2005 at 05:02:14PM -0800, David Daney wrote: > http://www.linux-mips.org/archives/linux-mips/2004-10/msg00068.html A little request - when posting references to mailing list postings or otherwise referecing them, please use the address that can be obtained by clicking at the "Permanent Link" neary the upper right of the posting. The resulting URL may be quite ugly but at least it won't change unlike the .../msg.html links that may change if I occasinally remove a posting from the archive such as spam. Ralf From jpfoster@exterity.co.uk Wed Feb 23 12:05:17 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 12:05:34 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:38301 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 12:05:17 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 12:06:35 +0000 Subject: Re: Big Endian au1550 From: JP Foster To: linux-mips@linux-mips.org In-Reply-To: <000301c5199d$3154ad40$0300a8c0@Exterity.local> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> Content-Type: text/plain Date: Wed, 23 Feb 2005 12:05:13 +0000 Message-Id: <1109160313.16445.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 12:06:35.0500 (UTC) FILETIME=[1EF8A2C0:01C519A0] 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: 7321 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: 1062 Lines: 28 Fair enough. Has anyone got big-endian au1xxx working ever? I'm reasonably flexible to use mipsel, since this is a new board, although all our other products are mipseb. Since big doesn't work as far as I can see. This must a regression as I'm sure I had built a running kernel a month or two back. Currently building a pre-christmas linux-mips snapshot to see if that works. If that doesn't work I'll just start using a mipsel version as I would be wary of using big endian if no one else is. JP On Wed, 2005-02-23 at 11:45 +0000, Ralf Baechle wrote: > >I recently rewrote the endianes selection in the Kconfig menus. The >individual platforms will now have to explicitly select >SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate >which endianess they support. I know that Alchemy supports big endian >operation in hardware but no idea if all the Linux code is working >properly, so I've been conservative and choose to limit the system >to little endian until somebody reports big endianess support to be >actually working. > > Ralf From ralf@linux-mips.org Wed Feb 23 13:23:35 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 13:23:51 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:13581 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 13:23:35 +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 j1NDHHSk013270; Wed, 23 Feb 2005 13:17:17 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1NDHHou013269; Wed, 23 Feb 2005 13:17:17 GMT Date: Wed, 23 Feb 2005 13:17:17 +0000 From: Ralf Baechle To: JP Foster Cc: linux-mips@linux-mips.org Subject: Re: Big Endian au1550 Message-ID: <20050223131717.GB9639@linux-mips.org> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109160313.16445.20.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: 7322 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: 19 On Wed, Feb 23, 2005 at 12:05:13PM +0000, JP Foster wrote: > Fair enough. Has anyone got big-endian au1xxx working ever? > I'm reasonably flexible to use mipsel, since this is a new board, > although all our other products are mipseb. > > Since big doesn't work as far as I can see. This must a regression > as I'm sure I had built a running kernel a month or two back. > Currently building a pre-christmas linux-mips snapshot to see if that > works. > > If that doesn't work I'll just start using a mipsel version as I would > be wary of using big endian if no one else is. Plenty of machines are using big endian and can't even be configured to little endian, so even in case you're hitting a problem it can't be very significant or even fundamental. Ralf From macro@linux-mips.org Wed Feb 23 14:05:33 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 14:05:49 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:61197 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 14:05:33 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 320ABF5978; Wed, 23 Feb 2005 15:05:24 +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 00898-04; Wed, 23 Feb 2005 15:05:24 +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 E0E3AE1CB4; Wed, 23 Feb 2005 15:05:23 +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 j1NE5MQW018863; Wed, 23 Feb 2005 15:05:22 +0100 Date: Wed, 23 Feb 2005 14:05:28 +0000 (GMT) From: "Maciej W. Rozycki" To: David Daney , libc-alpha@sources.redhat.com Cc: Jim Gifford , linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS In-Reply-To: <421BD616.4030101@avtrex.com> Message-ID: References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> 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: 7323 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: 2646 Lines: 62 On Tue, 22 Feb 2005, David Daney wrote: > > I'm trying to build the current glibc with my RaQ2, everything builds ok, > > until I start compiling strace. > > > > syscall.c: In function `dumpio': > > syscall.c:449: error: `SYS_read' undeclared (first use in this function) > > syscall.c:449: error: (Each undeclared identifier is reported only once > > syscall.c:449: error: for each function it appears in.) > > syscall.c:465: error: `SYS_write' undeclared (first use in this function) > > syscall.c: In function `syscall_fixup': > > syscall.c:1265: warning: unused variable `pid' > > syscall.c: In function `trace_syscall': > > syscall.c:2481: error: `SYS_exit' undeclared (first use in this function) > > make[1]: *** [syscall.o] Error 1 > > make[1]: Leaving directory `/usr/src/strace-4.5.9' > > make: *** [all] Error 2 > > > > Which leads me to check syscall.h, then I noticed a big difference from > > my x86 version to this version, all the SYS_ entries are missing. Did I > > build it wrong or is this a glibc issue, due to the addition of the > > mips32 and mips64 directories. > > > > Here is my bug report with the glibc folks for everyone's reference. > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=758 > > > > > It seems that you might need some (but not all) of the patch I posted here: > > http://www.linux-mips.org/archives/linux-mips/2004-10/msg00068.html > > Specifically I think you will need at least the parts that add > > #include > > To many of the .h files. Basically any file that uses the symbol _MIPS_SIM > and friends needs to either directly or indirectly include sgidefs.h > > You may also need: > > http://www.linux-mips.org/archives/linux-mips/2004-10/msg00142.html > > And something like this: > > http://sources.redhat.com/ml/libc-alpha/2004-11/msg00165.html The culprit is elsewhere. The glibc's syscall number translator script doesn't work with asm-mips/unistd.h as of Linux 2.6 (you could have probably used 2.4 headers instead; I'm not sure if that is compatible with "--enable-kernel=2.6.0", though). A correct fix has been prepared and proposed by Richard Sandiford and is available here: "http://sourceware.org/ml/libc-alpha/2004-11/msg00097.html". I would expect this patch to have been applied before 2.3.4, but apparently this hasn't happened. That's regrettable and I fear it's the result of glibc being somewhat inadequately maintained for MIPS/Linux these days, sigh... I'm not sure what the maintenance plan is for the 2.3 branch of glibc, but if 2.3.5 is ever going to happen, the Richard's patch is one of the must-have additions. Maciej From dan@embeddededge.com Wed Feb 23 15:03:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 15:03:34 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:24850 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 15:03:19 +0000 Received: from [192.168.2.27] (h69-21-252-132.69-21.unk.tds.net [69.21.252.132]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j1N3f1Hi009272; Tue, 22 Feb 2005 22:41:01 -0500 In-Reply-To: <1109160313.16445.20.camel@localhost.localdomain> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: linux-mips@linux-mips.org From: Dan Malek Subject: Re: Big Endian au1550 Date: Wed, 23 Feb 2005 10:03:01 -0500 To: JP Foster 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: 7324 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: 763 Lines: 23 On Feb 23, 2005, at 7:05 AM, JP Foster wrote: > Fair enough. Has anyone got big-endian au1xxx working ever? The only issues with big endian Au1xxx is the USB and potentially PCI. There have been recent patches posted for USB that could fix this. The PCI problem is with the read/write/in/out macros. They were never written properly and I haven't checked to see if this was corrected in 2.6. That aside, I have worked on several big endian Au1xxx projects that are successful. I never found a way, aside from #ifdefs for byte sex in generic files, to make the same source compile in either mode. It's a fairly low priority on my list of other Au1xxx projects :-) The Linux sources have worked, and if they currently don't we should fix them. -- Dan From ralf@linux-mips.org Wed Feb 23 15:12:50 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 15:13:04 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:45582 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 15:12:50 +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 j1NF6I0I018377; Wed, 23 Feb 2005 15:06:18 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1NF6Hfe018376; Wed, 23 Feb 2005 15:06:17 GMT Date: Wed, 23 Feb 2005 15:06:17 +0000 From: Ralf Baechle To: Dan Malek Cc: JP Foster , linux-mips@linux-mips.org Subject: Re: Big Endian au1550 Message-ID: <20050223150617.GA18290@linux-mips.org> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> 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: 7325 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: 920 Lines: 23 On Wed, Feb 23, 2005 at 10:03:01AM -0500, Dan Malek wrote: > >Fair enough. Has anyone got big-endian au1xxx working ever? > > The only issues with big endian Au1xxx is the USB and potentially > PCI. There have been recent patches posted for USB that could > fix this. The PCI problem is with the read/write/in/out macros. > They were never written properly and I haven't checked to see > if this was corrected in 2.6. > > That aside, I have worked on several big endian Au1xxx projects > that are successful. I never found a way, aside from #ifdefs for > byte sex in generic files, to make the same source compile in > either mode. It's a fairly low priority on my list of other Au1xxx > projects :-) > > The Linux sources have worked, and if they currently don't we > should fix them. So I guess this would apply to all Alchemy-based platforms and thus I should offer big endian on all of them again? Ralf From sailer@scs.ch Wed Feb 23 16:59:03 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 16:59:19 +0000 (GMT) Received: from mail.scs.ch ([IPv6:::ffff:212.254.229.5]:50307 "EHLO mail.scs.ch") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 16:59:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.scs.ch (8.12.11/8.12.11) with ESMTP id j1NGvfRn010233; Wed, 23 Feb 2005 17:57:41 +0100 Received: from mail.scs.ch ([127.0.0.1]) by localhost (mail.scs.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10151-03; Wed, 23 Feb 2005 17:57:39 +0100 (CET) Received: from kronenbourg.scs.ch (190.scs.ch [212.254.229.190]) by mail.scs.ch (8.12.11/8.12.11) with ESMTP id j1NGvaqf010227; Wed, 23 Feb 2005 17:57:36 +0100 Subject: Re: Big Endian au1550 From: Thomas Sailer To: Dan Malek Cc: JP Foster , linux-mips@linux-mips.org In-Reply-To: References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> Content-Type: text/plain Organization: SCS Date: Wed, 23 Feb 2005 17:57:36 +0100 Message-Id: <1109177856.18018.13.camel@kronenbourg.scs.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at scs.ch 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: 7326 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: sailer@scs.ch Precedence: bulk X-list: linux-mips Content-Length: 463 Lines: 13 On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote: > The only issues with big endian Au1xxx is the USB and potentially > PCI. There have been recent patches posted for USB that could > fix this. The PCI problem is with the read/write/in/out macros. Last time I tried (about a month ago using the then current linux-mips 2.6 CVS tree), USB host didn't work neither in big nor little endian mode on my AMD Pb1000. Ethernet and Serial worked either way. Tom From dan@embeddededge.com Wed Feb 23 17:03:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 17:03:24 +0000 (GMT) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:42258 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 17:03: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 j1N5edHi009465; Wed, 23 Feb 2005 00:40:39 -0500 In-Reply-To: <20050223150617.GA18290@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 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: JP Foster , linux-mips@linux-mips.org From: Dan Malek Subject: Re: Big Endian au1550 Date: Wed, 23 Feb 2005 12:02:47 -0500 To: Ralf Baechle 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: 7327 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: 275 Lines: 14 On Feb 23, 2005, at 10:06 AM, Ralf Baechle 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 :-) Thanks. -- Dan From ppopov@embeddedalley.com Wed Feb 23 17:47:32 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 17:47:47 +0000 (GMT) Received: from mail.chipsandsystems.com ([IPv6:::ffff:64.164.196.27]:967 "EHLO mail.chipsag.com") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 17:47:32 +0000 Received: from [10.1.100.35] ([10.1.100.35]) by mail.chipsag.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Feb 2005 09:50:34 -0800 Message-ID: <421CC1AA.4070201@embeddedalley.com> Date: Wed, 23 Feb 2005 09:47:22 -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/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Sailer CC: Dan Malek , JP Foster , linux-mips@linux-mips.org Subject: Re: Big Endian au1550 References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> <1109177856.18018.13.camel@kronenbourg.scs.ch> In-Reply-To: <1109177856.18018.13.camel@kronenbourg.scs.ch> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 17:50:34.0885 (UTC) FILETIME=[2D00DB50:01C519D0] 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: 7328 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: 636 Lines: 17 Thomas Sailer wrote: > On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote: > > >>The only issues with big endian Au1xxx is the USB and potentially >>PCI. There have been recent patches posted for USB that could >>fix this. The PCI problem is with the read/write/in/out macros. > > > Last time I tried (about a month ago using the then current linux-mips > 2.6 CVS tree), USB host didn't work neither in big nor little endian > mode on my AMD Pb1000. Ethernet and Serial worked either way. We've been doing all the 2.6 work on the Db1x boards. The Pb1x need an uplift as well, but I don't know if we'll have time to do it. Pete From vprashant@echelon.com Wed Feb 23 18:30:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Feb 2005 18:31:11 +0000 (GMT) Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:60685 "EHLO [205.229.50.10]") by linux-mips.org with ESMTP id ; Wed, 23 Feb 2005 18:30:56 +0000 Received: from miles.echelon.com by [205.229.50.10] via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Wed, 23 Feb 2005 10:30:55 -0800 Received: by miles.echelon.com with Internet Mail Service (5.5.2653.19) id <19FLPZRC>; Wed, 23 Feb 2005 10:30:53 -0800 Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB5901654513@miles.echelon.com> From: Prashant Viswanathan To: 'JP Foster' , linux-mips@linux-mips.org Subject: RE: Big Endian au1550 Date: Wed, 23 Feb 2005 10:30:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: 7329 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: vprashant@echelon.com Precedence: bulk X-list: linux-mips Content-Length: 1262 Lines: 35 > On Wed, 2005-02-23 at 11:45 +0000, Ralf Baechle wrote: > > > >I recently rewrote the endianes selection in the Kconfig menus. The > >individual platforms will now have to explicitly select > >SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate > >which endianess they support. I know that Alchemy supports big endian > >operation in hardware but no idea if all the Linux code is working > >properly, so I've been conservative and choose to limit the system > >to little endian until somebody reports big endianess support to be > >actually working. > > > > Ralf > > > Fair enough. Has anyone got big-endian au1xxx working ever? > I'm reasonably flexible to use mipsel, since this is a new board, > although all our other products are mipseb. > > Since big doesn't work as far as I can see. This must a regression > as I'm sure I had built a running kernel a month or two back. > Currently building a pre-christmas linux-mips snapshot to see if that > works. > > If that doesn't work I'll just start using a mipsel version as I would > be wary of using big endian if no one else is. > > JP I have Au1550 running in big endian mode and Linux kernel running on it. The Linux kernel was compiled big endian using BE toolchain. Prashant From cilelaider@sarapun.com Thu Feb 24 01:58:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 01:58:53 +0000 (GMT) Received: from [IPv6:::ffff:218.74.248.30] ([IPv6:::ffff:218.74.248.30]:25099 "HELO sarapun.com") by linux-mips.org with SMTP id ; Thu, 24 Feb 2005 01:58:37 +0000 Message-ID: Reply-To: "parker mcgraw" From: "parker mcgraw" To: "Dee Wingfield" Subject: Nice and easy online shopping for brand name inks Date: Wed, 23 Feb 2005 23:35:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 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: 7330 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: cilelaider@sarapun.com Precedence: bulk X-list: linux-mips Content-Length: 1070 Lines: 32 If you want to get top quality ink products at the best prices, please check our site for a full range of quality inks on sale. With a wide selection on name brands like Apple, NEC, Lexmark, Compaq, Brother, Epson, Canon, HP and more others online, customers can choose quality products at the best prices online. Choose to save on ink products. It is the No.1 choice for super saving. For US orders, the shipping takes 2 to 3 days. For orders over 45 dollars within the states, shipping is frree. If you need more coupons or just want to know more about the new special, contact the support team for assistance. For a huge selection of ink toners and cartridges please check the site now. http://qw.6.newtalesmile.com/5w9/ for secretary of state, Rice traveled solo to China, Japan and South Korea. In Beijing, sheof writing.Reading quickly boosts the productivity of the scorers, who are paid as much as long, they become too analytical," she says. In the world of holistic scoring, "analytical" contrarotation6 conchyliated 6asphalter collegially belief From jpfoster@exterity.co.uk Thu Feb 24 10:05:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 10:05:18 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:43699 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 10:05:02 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 10:06:20 +0000 Subject: Re: Big Endian au1550 From: JP Foster To: ppopov@embeddedalley.com Cc: linux-mips@linux-mips.org In-Reply-To: <000001c519d1$84d9c250$0300a8c0@Exterity.local> References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> <1109177856.18018.13.camel@kronenbourg.scs.ch> <000001c519d1$84d9c250$0300a8c0@Exterity.local> Content-Type: text/plain Date: Thu, 24 Feb 2005 10:04:55 +0000 Message-Id: <1109239495.8389.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2005 10:06:20.0546 (UTC) FILETIME=[7CEFC620:01C51A58] 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: 7331 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: 1087 Lines: 30 On Wed, 2005-02-23 at 18:00 +0000, Pete Popov wrote: >Thomas Sailer wrote: >> On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote: >> >> >>>The only issues with big endian Au1xxx is the USB and potentially >>>PCI. There have been recent patches posted for USB that could >>>fix this. The PCI problem is with the read/write/in/out macros. >> >> >> Last time I tried (about a month ago using the then current linux-mips >> 2.6 CVS tree), USB host didn't work neither in big nor little endian >> mode on my AMD Pb1000. Ethernet and Serial worked either way. > >We've been doing all the 2.6 work on the Db1x boards. The Pb1x need >an uplift as well, but I don't know if we'll have time to do it. > >Pete > Great, but I still can't get a running kernel from cvs mips-linux for a DB1550 board. Is it perhaps the toolchain? I'm using gcc-3.4.1 perhaps that is too recent. Tried mipsel last night and got the same result as big end so I suspect it may be my compiler/binutils combination. Is there are recommended toolchain for mips. Should I go build gcc-2.95 and binutils 2.12 ? JP From kumba@gentoo.org Thu Feb 24 14:37:39 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 14:37:55 +0000 (GMT) Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:27058 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 14:37:39 +0000 Received: from [192.168.1.4] (pcp05077810pcs.waldrf01.md.comcast.net[68.54.246.193]) by comcast.net (sccrmhc11) with ESMTP id <2005022414372801100stlu3e>; Thu, 24 Feb 2005 14:37:29 +0000 Message-ID: <421DE686.6040003@gentoo.org> Date: Thu, 24 Feb 2005 09:36:54 -0500 From: Kumba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: libc-alpha@sources.redhat.com, linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> In-Reply-To: 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: 7332 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: 1312 Lines: 30 Maciej W. Rozycki wrote: > > The culprit is elsewhere. The glibc's syscall number translator script > doesn't work with asm-mips/unistd.h as of Linux 2.6 (you could have > probably used 2.4 headers instead; I'm not sure if that is compatible with > "--enable-kernel=2.6.0", though). A correct fix has been prepared and > proposed by Richard Sandiford and is available here: > "http://sourceware.org/ml/libc-alpha/2004-11/msg00097.html". I would > expect this patch to have been applied before 2.3.4, but apparently this > hasn't happened. That's regrettable and I fear it's the result of glibc > being somewhat inadequately maintained for MIPS/Linux these days, sigh... > > I'm not sure what the maintenance plan is for the 2.3 branch of glibc, > but if 2.3.5 is ever going to happen, the Richard's patch is one of the > must-have additions. > > Maciej The debian patch I referenced is what we require for glibc to generate a proper syscalls.h for 2.4 kernels. Unknown on the 2.6 kernel front how that patch affects things. I'll have to see if this patch affects/changes anything for either headers version. --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 690190029@s90.tku.edu.tw Thu Feb 24 15:53:56 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 15:54:12 +0000 (GMT) Received: from msr58.hinet.net ([IPv6:::ffff:168.95.4.158]:16082 "EHLO msr58.hinet.net") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 15:53:56 +0000 Received: from [192.168.186.100] (218-160-24-140.dynamic.hinet.net [218.160.24.140]) by msr58.hinet.net (8.9.3/8.9.3) with ESMTP id XAA18254 for ; Thu, 24 Feb 2005 23:53:51 +0800 (CST) Message-ID: <421DF870.30708@s90.tku.edu.tw> Date: Thu, 24 Feb 2005 23:53:20 +0800 From: Tsang-Ren Chang <690190029@s90.tku.edu.tw> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: ADM5120: Data bus error Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 8bit Return-Path: <690190029@s90.tku.edu.tw> 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: 7333 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: 690190029@s90.tku.edu.tw Precedence: bulk X-list: linux-mips Content-Length: 5247 Lines: 154 Hi, I'm porting linux-2.4.27 on adm5120 (MIPS 4Kc core). But when I copied /sbin/pppd , It crashed. ADM5120 Boot: no sys signature found!! jump to linux code!! LINUX started... ADM5120 Demo board CPU revision is: 0001800b Primary instruction cache 8kB, physically tagged, 2-way, linesize 16 bytes. Primary data cache 8kB 2-way, linesize 16 bytes. Linux version 2.4.27 (neo@neo) (gcc version 2.96 20000731 (Red Hat Li nux 7.3 2.96-110.1)) #498 ¥| 2¤ë 24 21:41:56 CST 2005 am5120_setup() starts. System has PCI BIOS Determined physical RAM map: memory: 00d4a000 @ 002b6000 (usable) Initial ramdisk at: 0x80180000 (1122304 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram0 console=ttyS0 CPU clock: 175MHz No external timer interrupt -- use R4k. Using 87.500 MHz high precision timer. Calibrating delay loop... 174.48 BogoMIPS Memory: 13420k/13608k available (1334k kernel code, 188k reserved, 1180k data, 9 2k init, 0k highmem) Dentry cache hash table entries: 2048 (order: 2, 16384 bytes) Inode cache hash table entries: 1024 (order: 1, 8192 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Checking for 'wait' instruction... available. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 256 Unix98 ptys configured HDLC line discipline: version $Revision: 3.7 $, maxframe=4096 N_HDLC line discipline registered. RAMDISK driver initialized: 16 RAM disks of 5120K size 1024 blocksize loop: loaded (max 8 devices) ADM5120 Switch Module Init PPP generic driver version 2.4.2 MX29LV160B flash device: 200000 at 1fc00000 Amd/Fujitsu Extended Query Table v1.0 at 0x0040 MX29LV320B flash device initialized ftl_cs: FTL header not found. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 2048) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 LED & GPIO Driver v1.0 RAMDISK: Compressed image found at block 0 Uncompressing....... done Freeing initrd memory: 1096k freed VFS: Mounted root (ext2 filesystem). Freeing prom memory: 0kb freed Freeing unused kernel memory: 92k freed Please press Enter to activate this console. BusyBox v1.00-pre7 (2004.11.29-08:57+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. # # cp /sbin/pppd /tmp/ Data bus error, epc == 8012a824, ra == 800972b8 Oops in traps.c::do_be, line 387: $0 : 00000000 802a5ca8 8026d000 00000000 8026d300 80ffff00 000000e0 8026d000 $8 : afbe0020 92450000 00000000 24a3ffff 03c4102a 0000026d ba2e8ba3 10400003 $16: 802e3ff4 00000400 00000000 00000000 80276f60 0000007f ba2e8ba3 8038fe3c $24: 00000000 00000000 80260000 80261d30 00000000 800972b8 Hi : ffff400c Lo : 00003ffc epc : 8012a824 Not tainted Status: 10008403 Cause : 1080001c PrId : 0001800b Process cp (pid: 28, stackpage=80260000) Stack: 80226720 00000001 80276e40 802beaf4 00000000 80261e04 80276f60 00000002 000003f6 00001400 00000000 80261e08 00000004 8003e94c 802beadc 800973b4 0000000c 0000005f 00000001 00000000 80276f60 80095690 00000000 8031697c 000001fe 80226420 80276f00 8003f5a8 80276f70 80276f60 00000001 00000002 00000000 80095764 80261db0 0000001a 80276e40 802beaf4 0000006b 80261e04 ... Call Trace: [<8003e94c>] [<800973b4>] [<80095690>] [<8003f5a8>] [<80095764>] [<800405a0>] [<8006b320>] [<8002e490>] [<8006ae20>] [<8012a824>] [<8002b4bc>] [<8002b3d8>] [<8002bbf4>] [<8002baa4>] [<8003c430>] [<8003c60c>] [<8003bd7c>] [<8000bca4>] [<8000be08>] [<8012abe8>] [<80062fec>] Code: 8caa0008 8cab000c 24c6ffe0 <8cac0010> 8caf0014 ac880000 ac890004 8ca8 0018 8ca9001c Segmentation fault 8012a7f8 : 8012a7f8: 00064142 srl t0,a2,0x5 8012a7fc: 1100001b beqz t0,8012a86c 8012a800: 30d8001f andi t8,a2,0x1f 8012a804: cca00060 lwc3 $0,96(a1) 8012a808: cc810060 lwc3 $1,96(a0) 8012a80c: 00000000 nop 8012a810: 8ca80000 lw t0,0(a1) 8012a814: 8ca90004 lw t1,4(a1) 8012a818: 8caa0008 lw t2,8(a1) 8012a81c: 8cab000c lw t3,12(a1) 8012a820: 24c6ffe0 addiu a2,a2,-32 8012a824: 8cac0010 lw t4,16(a1) 8012a828: 8caf0014 lw t7,20(a1) 8012a82c: ac880000 sw t0,0(a0) 8012a830: ac890004 sw t1,4(a0) 8012a834: 8ca80018 lw t0,24(a1) 8012a838: 8ca9001c lw t1,28(a1) 8012a83c: 24a50020 addiu a1,a1,32 8012a840: 24840020 addiu a0,a0,32 8012a844: ac8affe8 sw t2,-24(a0) 8012a848: ac8bffec sw t3,-20(a0) 8012a84c: ac8cfff0 sw t4,-16(a0) 8012a850: ac8ffff4 sw t7,-12(a0) 8012a854: ac88fff8 sw t0,-8(a0) 8012a858: ac89fffc sw t1,-4(a0) 8012a85c: cca00100 lwc3 $0,256(a1) 8012a860: cc810100 lwc3 $1,256(a0) 8012a864: 14d8ffea bne a2,t8,8012a810 8012a868: 00000000 nop I tried to ignore this exception(return from do_be() immediately) and compared /tmp/pppd with original pppd. I'm confused now because they are all equivalent. Why does the CPU raise data bus error exception when I copy or read /sbin/pppd every time? (cp0 hazards?) How to fix this? Thanks. T.R. Chang From ppopov@embeddedalley.com Thu Feb 24 16:15:51 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 16:16:05 +0000 (GMT) Received: from web203.biz.mail.re2.yahoo.com ([IPv6:::ffff:68.142.224.165]:30338 "HELO web203.biz.mail.re2.yahoo.com") by linux-mips.org with SMTP id ; Thu, 24 Feb 2005 16:15:51 +0000 Message-ID: <20050224161542.74749.qmail@web203.biz.mail.re2.yahoo.com> Received: from [63.194.214.47] by web203.biz.mail.re2.yahoo.com via HTTP; Thu, 24 Feb 2005 08:15:41 PST Date: Thu, 24 Feb 2005 08:15:41 -0800 (PST) From: Peter Popov Subject: Re: Big Endian au1550 To: JP Foster Cc: linux-mips@linux-mips.org In-Reply-To: <1109239495.8389.8.camel@localhost.localdomain> 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: 7334 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: 625 Lines: 22 > Great, but I still can't get a running kernel from > cvs mips-linux for > a DB1550 board. Is it perhaps the toolchain? I'm > using gcc-3.4.1 perhaps that is too recent. Either that or something broke recently. I'll boot a kernel tonight to make sure it still ok. > Tried mipsel last night and got the same result as > big end so I suspect > it may be my compiler/binutils combination. Is there > are recommended > toolchain for mips. Should I go build gcc-2.95 and > binutils 2.12 ? 2.95 is too old. We're using 3.3.3 and binutils 2.15. We're working on making a toolkit available soon, or you can try ELDK3.0. Pete From clem.taylor@gmail.com Thu Feb 24 16:19:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 16:20:14 +0000 (GMT) Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.198]:20590 "EHLO wproxy.gmail.com") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 16:19:59 +0000 Received: by wproxy.gmail.com with SMTP id 57so160279wri for ; Thu, 24 Feb 2005 08:19:53 -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=kE0EyGiiVMRhY6pekpMaFZlYDjNTHsgk6FTLAsnQRzzzNKJjn2/0VIhkGuOlXb1gFA/0htn/WAZHP72WPiMsQZGbmFYbCe59xCdaNw3uT3FOtqt7ezr29RrMl6QFJfFJ0DbeG2W/Q2SfehquLiPaPhqIvkwwVV4kHAY2zAWSkbc= Received: by 10.54.7.72 with SMTP id 72mr62213wrg; Thu, 24 Feb 2005 08:19:52 -0800 (PST) Received: by 10.54.41.3 with HTTP; Thu, 24 Feb 2005 08:19:51 -0800 (PST) Message-ID: Date: Thu, 24 Feb 2005 11:19:51 -0500 From: Clem Taylor Reply-To: Clem Taylor To: JP Foster Subject: Re: Big Endian au1550 Cc: linux-mips@linux-mips.org In-Reply-To: <1109239495.8389.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1109157737.16445.6.camel@localhost.localdomain> <000301c5199d$3154ad40$0300a8c0@Exterity.local> <1109160313.16445.20.camel@localhost.localdomain> <1109177856.18018.13.camel@kronenbourg.scs.ch> <000001c519d1$84d9c250$0300a8c0@Exterity.local> <1109239495.8389.8.camel@localhost.localdomain> 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: 7335 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: clem.taylor@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1030 Lines: 21 > Great, but I still can't get a running kernel from cvs mips-linux for > a DB1550 board. Is it perhaps the toolchain? I'm using gcc-3.4.1 perhaps > that is too recent. > > Tried mipsel last night and got the same result as big end so I suspect > it may be my compiler/binutils combination. Is there are recommended > toolchain for mips. Should I go build gcc-2.95 and binutils 2.12 ? I'm not sure about mipseb, but I've used both crosstool and buildroot to build toolchains to compile a mipsel 2.6.10 kernel for the DBAu1550. The kernel is the linux-mips cvs head from a few weeks ago. Right now I'm using gcc 3.4.3 and binutils 2.15.94.0.2 20041220 that was built with a recent buildroot checkout. When I first tried to compile the 2.6.10 I was using crosstool-0.28-rc37 and I ran into some binutils issues. I ended up using gcc-3.4.1-glibc-2.3.2 with binutils-050110 (I'm not sure where I got that). When I switched to buildroot I was able to use the latest tools it had support for. --Clem From jpfoster@exterity.co.uk Thu Feb 24 17:09:34 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 17:09:48 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:50625 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 17:09:34 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 17:10:52 +0000 Subject: Re: Big Endian au1550 From: JP Foster To: Peter Popov Cc: linux-mips@linux-mips.org In-Reply-To: <20050224161542.74749.qmail@web203.biz.mail.re2.yahoo.com> References: <20050224161542.74749.qmail@web203.biz.mail.re2.yahoo.com> Content-Type: text/plain Date: Thu, 24 Feb 2005 17:09:26 +0000 Message-Id: <1109264967.8690.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2005 17:10:52.0265 (UTC) FILETIME=[CB43A590:01C51A93] 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: 7336 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: 311 Lines: 12 >2.95 is too old. We're using 3.3.3 and binutils 2.15. >We're working on making a toolkit available soon, or >you can try ELDK3.0. > Thanks I'll try that. Thanks to everyone for all their help and advice. I *WILL* get this built. It usually isn't this hard :) -- jp.foster@exterity.co.uk Digital Simplicity From maillist@jg555.com Thu Feb 24 17:21:38 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 17:21:55 +0000 (GMT) Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:28055 "EHLO jg555.com") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 17:21:38 +0000 Received: from [172.16.0.150] (w2rz8l4s02.jg555.com [::ffff:172.16.0.150]) (AUTH: PLAIN jim, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Thu, 24 Feb 2005 09:21:32 -0800 id 00008498.421E0D1C.00002DE4 Message-ID: <421E0D08.3070106@jg555.com> Date: Thu, 24 Feb 2005 09:21:12 -0800 From: Jim Gifford User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_server-11748-1109265693-0001-2" To: Kumba CC: "Maciej W. Rozycki" , libc-alpha@sources.redhat.com, linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> <421DE686.6040003@gentoo.org> In-Reply-To: <421DE686.6040003@gentoo.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: 7337 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: 11771 Lines: 277 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server-11748-1109265693-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I updated the patch, that was posted in libc-alpha and I have tested it. Thanx to you all for your assistance. http://ftp.jg555.com/patches/raq2/glibc/glibc-2.3.4-mips_syscall-2.patch --=_server-11748-1109265693-0001-2 Content-Type: text/x-patch; name="glibc-2.3.4-mips_syscall-2.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="glibc-2.3.4-mips_syscall-2.patch" Submitted By: Jim Gifford (patches at jg555 dot com) Date: 2005-02-23 Initial Package Version: 2.3.4 Origin: Richard Sandiford Upstream Status: Unknown Description: Fixes Syscall.h generation diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/Makefile glibc-2.3.4/sysdeps/unix/sysv/linux/mips/Makefile --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/Makefile 2004-11-24 04:38:15 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/Makefile 2005-02-23 18:21:54 +0000 @@ -9,11 +9,73 @@ no_syscall_list_h = 1 -# Generate the list of SYS_* macros for the system calls (__NR_* macros). -# We generate not only SYS_, pointing at SYS__ if -# it exists, but also define SYS__ for all ABIs. +# A callable macro that expands to a shell command. Preprocess file $(1) +# using ABI option $(2) and see which macros it defines. Print FOO for each +# macro of the form __NR$(3)_FOO, filtering out ABI-specific __NR macros +# that have a prefix other than $(3). +mips_list_syscalls = $(filter-out -m%,$(CC)) -E -x c $(+includes) \ + $(sysincludes) -D_LIBC -dM -mabi=$(2) $(1) | \ + sed -n 's@^\#define __NR$(3)_\([^ ]*\) .*@\1@p' | \ + sed -e '/^[ON]32_/d' -e '/^N64_/d' -e '/^64_/d' | \ + LC_ALL=C sort + +# Generate a list of SYS_* macros from the linux __NR macros. +# +# Before version 2.6, linux had separate 32-bit and 64-bit MIPS ports, +# each with its own set of headers. The ports were merged for 2.6 and +# this merged port defines the syscalls in a slightly different way. +# There are therefore three sets of headers that we need to consider: +# +# (1) Headers from the separate 32-bit MIPS port. They just define +# a single list of __NR macros. +# +# (2) Headers from the separate 64-bit MIPS port. They unconditionally +# define syscalls for all three ABIs, with o32 syscalls prefixed +# by __NR_O32, n32 syscalls prefixed by __NR_N32 and n64 syscalls +# prefixed by plain __NR. +# +# (3) Headers from the combined port. They use the _MIPS_SIM macro to +# define the right set of syscalls for the current ABI. The syscalls +# themselves have no special ABI prefix, but the headers also define: +# +# __NR_O32_Linux{,_syscalls} +# __NR_N32_Linux{,_syscalls} +# __NR_64_Linux{,_syscalls} +# +# In case (1) we just want a simple list of SYS_* macros. In cases (2) +# and (3) we want a file that will work for all three ABIs, regardless +# of which ABI we are currently using. We also want the file to work +# if the user later moves from (2) to (3). Thus the file we create +# for (2) and (3) has the form: +# +# #if _MIPS_SIM == _MIPS_SIM_NABI32 +# # ifdef __NR_N32_open +# # define SYS_n32syscall1 __NR_N32_n32syscall1 +# # ... +# # else +# # define SYS_n32syscall1 __NR_n32syscall1 +# # ... +# # endif +# #elif _MIPS_SIM == _MIPS_SIM_ABI64 +# # define SYS_n64syscall1 __NR_n64syscall1 +# # ... +# #else +# # ifdef __NR_O32_open +# # define SYS_o32syscall1 __NR_O32_o32syscall1 +# # ... +# # else +# # define SYS_o32syscall1 __NR_o32syscall1 +# # ... +# # endif +# #endif +# +# Here, __NR_N32_open and __NR_O32_open are used to detect case (2) +# over case (3). The n64 SYS_* macros can always use the normal +# ABI-less names. $(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/mips/sys/syscall.h $(make-target-directory) + $(CC) -E -x c $(+includes) $(sysincludes) -D_LIBC $< -MD -MP \ + -MF $(@:.h=.d)-t -MT '$(@:.d=.h) $(@:.h=.d)' > /dev/null { \ echo '/* Generated at libc build time from kernel syscall list. */';\ echo ''; \ @@ -22,28 +84,38 @@ echo '#endif'; \ echo ''; \ echo '#include '; \ - rm -f $(@:.d=.h).newt; \ - $(CC) -E -MD -MP -MF $(@:.h=.d)-t -MT '$(@:.d=.h) $(@:.h=.d)' \ - -x c $(+includes) $(sysincludes) $< -D_LIBC -dM | \ - sed -n 's@^#define __NR_\([^ ]*\) .*$$@#define SYS_\1 __NR_\1@p' \ - > $(@:.d=.h).newt; \ - if grep SYS_O32_ $(@:.d=.h).newt > /dev/null; then \ + rm -f $(@:.d=.h).new32 $(@:.d=.h).newn32 $(@:.d=.h).new64; \ + $(call mips_list_syscalls,$<,n32,_N32) > $(@:.d=.h).newn32; \ + if test -s $(@:.d=.h).newn32; then \ + if grep open $(@:.d=.h).newn32 > /dev/null; then \ + $(call mips_list_syscalls,$<,32,_O32) > $(@:.d=.h).new32; \ + $(call mips_list_syscalls,$<,64,) > $(@:.d=.h).new64; \ + else \ + $(call mips_list_syscalls,$<,32,) > $(@:.d=.h).new32; \ + $(call mips_list_syscalls,$<,n32,) > $(@:.d=.h).newn32; \ + $(call mips_list_syscalls,$<,64,) > $(@:.d=.h).new64; \ + fi; \ echo '#if _MIPS_SIM == _ABIN32'; \ - sed -n 's/^\(#define SYS_\)N32_/\1/p' < $(@:.d=.h).newt | \ - LC_ALL=C sort; \ + echo '# ifdef __NR_N32_open'; \ + sed 's@\(.*\)@# define SYS_\1 __NR_N32_\1@' < $(@:.d=.h).newn32; \ + echo '# else'; \ + sed 's@\(.*\)@# define SYS_\1 __NR_\1@' < $(@:.d=.h).newn32; \ + echo '# endif'; \ echo '#elif _MIPS_SIM == _ABI64'; \ - sed -n 's/^\(#define SYS_\)N64_/\1/p' < $(@:.d=.h).newt | \ - LC_ALL=C sort; \ + sed 's@\(.*\)@# define SYS_\1 __NR_\1@' < $(@:.d=.h).new64; \ echo '#else'; \ - sed -n 's/^\(#define SYS_\)O32_/\1/p' < $(@:.d=.h).newt | \ - LC_ALL=C sort; \ + echo '# ifdef __NR_O32_open'; \ + sed 's@\(.*\)@# define SYS_\1 __NR_O32_\1@' < $(@:.d=.h).new32; \ + echo '# else'; \ + sed 's@\(.*\)@# define SYS_\1 __NR_\1@' < $(@:.d=.h).new32; \ + echo '# endif'; \ echo '#endif'; \ - sed -n '/^#define SYS_\([ON]32\|N64\)_/p' < $(@:.d=.h).newt | \ - LC_ALL=C sort +1.8; \ else \ - cat $(@:.d=.h).newt; \ + $(CC) -E -x c $(+includes) $(sysincludes) -D_LIBC -dM $< | \ + sed -n 's@^\#define __NR_\([^ ]*\) .*@\#define SYS_\1 __NR_\1@p' | \ + LC_ALL=C sort; \ fi; \ - rm $(@:.d=.h).newt; \ + rm -f $(@:.d=.h).new32 $(@:.d=.h).newn32 $(@:.d=.h).new64; \ } > $(@:.d=.h).new mv -f $(@:.d=.h).new $(@:.d=.h) ifneq (,$(objpfx)) diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/configure glibc-2.3.4/sysdeps/unix/sysv/linux/mips/configure --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/configure 2004-11-24 04:42:45 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/configure 2005-02-23 18:10:11 +0000 @@ -18,7 +18,7 @@ { echo "$as_me:$LINENO: WARNING: *** asm/unistd.h not found, it will not be pre-processed" >&5 echo "$as_me: WARNING: *** asm/unistd.h not found, it will not be pre-processed" >&2;} echo '#include ' > asm-unistd.h - else + elif grep __NR_N32_open "$asm_unistd_h" > /dev/null; then # The point of this preprocessing is to turn __NR_ into # __NR_N64_, as well as to define __NR_ to # __NR__, if __NR__ is defined @@ -68,6 +68,8 @@ { print; }' + else + echo '#include ' > asm-unistd.h fi ;; mips*) rm -f asm-unistd.h diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/configure.in glibc-2.3.4/sysdeps/unix/sysv/linux/mips/configure.in --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/configure.in 2004-11-24 04:38:31 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/configure.in 2005-02-23 18:10:11 +0000 @@ -18,7 +18,7 @@ if test ! -f "$asm_unistd_h"; then AC_MSG_WARN([*** asm/unistd.h not found, it will not be pre-processed]) echo '#include ' > asm-unistd.h - else + elif grep __NR_N32_open "$asm_unistd_h" > /dev/null; then # The point of this preprocessing is to turn __NR_ into # __NR_N64_, as well as to define __NR_ to # __NR__, if __NR__ is defined @@ -68,6 +68,8 @@ { print; }' + else + echo '#include ' > asm-unistd.h fi ;; mips*) rm -f asm-unistd.h diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips32/kern64/sysdep.h glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips32/kern64/sysdep.h --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips32/kern64/sysdep.h 2003-03-29 08:15:29 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips32/kern64/sysdep.h 2005-02-23 18:10:11 +0000 @@ -1,36 +0,0 @@ -/* Copyright (C) 2000, 2002, 2003 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - The GNU C Library 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 - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA - 02111-1307 USA. */ - -#ifndef _LINUX_MIPS_MIPS32_KERN64_SYSDEP_H -#define _LINUX_MIPS_MIPS32_KERN64_SYSDEP_H 1 - -/* There is some commonality. */ -#include - -/* For Linux we can use the system call table in the header file - /usr/include/asm/unistd.h - of the kernel. But these symbols do not follow the SYS_* syntax - so we have to redefine the `SYS_ify' macro here. */ -#undef SYS_ify -#ifdef __STDC__ -# define SYS_ify(syscall_name) __NR_O32_##syscall_name -#else -# define SYS_ify(syscall_name) __NR_O32_/**/syscall_name -#endif - -#endif /* linux/mips/mips32/kern64/sysdep.h */ diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h 2004-10-18 05:16:07 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h 2005-02-23 18:10:11 +0000 @@ -28,9 +28,9 @@ so we have to redefine the `SYS_ify' macro here. */ #undef SYS_ify #ifdef __STDC__ -# define SYS_ify(syscall_name) __NR_N32_##syscall_name +# define SYS_ify(syscall_name) __NR_##syscall_name #else -# define SYS_ify(syscall_name) __NR_N32_/**/syscall_name +# define SYS_ify(syscall_name) __NR_/**/syscall_name #endif #ifdef __ASSEMBLER__ diff -Naur glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h --- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h 2004-10-18 05:16:08 +0000 +++ glibc-2.3.4/sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h 2005-02-23 18:10:11 +0000 @@ -28,9 +28,9 @@ so we have to redefine the `SYS_ify' macro here. */ #undef SYS_ify #ifdef __STDC__ -# define SYS_ify(syscall_name) __NR_N64_##syscall_name +# define SYS_ify(syscall_name) __NR_##syscall_name #else -# define SYS_ify(syscall_name) __NR_N64_/**/syscall_name +# define SYS_ify(syscall_name) __NR_/**/syscall_name #endif #ifdef __ASSEMBLER__ --=_server-11748-1109265693-0001-2-- From macro@linux-mips.org Thu Feb 24 18:04:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 18:04:24 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:32529 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 18:04:08 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 92468E1CB5; Thu, 24 Feb 2005 19:03:57 +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 20697-02; Thu, 24 Feb 2005 19:03:57 +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 3798AE1C6D; Thu, 24 Feb 2005 19:03:57 +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 j1OI40E1029549; Thu, 24 Feb 2005 19:04:01 +0100 Date: Thu, 24 Feb 2005 18:04:09 +0000 (GMT) From: "Maciej W. Rozycki" To: Tsang-Ren Chang <690190029@s90.tku.edu.tw> Cc: linux-mips@linux-mips.org Subject: Re: ADM5120: Data bus error In-Reply-To: <421DF870.30708@s90.tku.edu.tw> Message-ID: References: <421DF870.30708@s90.tku.edu.tw> 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: 7338 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: 864 Lines: 17 On Thu, 24 Feb 2005, Tsang-Ren Chang wrote: > Why does the CPU raise data bus error exception when I copy or read > /sbin/pppd every time? (cp0 hazards?) Bus error exceptions are triggered by an external signal, i.e. they come from board logic (the chipset). See your board's documentation for what can cause them. If the chipset provides any additional information for bus errors, you may decode it or at least dump in your own board-specific handler -- see the board_be_init variable for how to provide it and arch/mips/dec/ecc-berr.c for a reasonable working implementation. You may request the generic handler to ignore a bus error exception if the additional information from the chipset shows it's a recoverable condition, like an ECC-corrected memory error (it shouldn't normally use bus errors for signalling such events, though). Maciej From macro@linux-mips.org Thu Feb 24 19:51:24 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Feb 2005 19:51:40 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:45319 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 24 Feb 2005 19:51:24 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 60B63E1CBC; Thu, 24 Feb 2005 20:51:16 +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 06942-07; Thu, 24 Feb 2005 20:51:16 +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 14065E1CB5; Thu, 24 Feb 2005 20:51:16 +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 j1OJpGpt002603; Thu, 24 Feb 2005 20:51:16 +0100 Date: Thu, 24 Feb 2005 19:51:26 +0000 (GMT) From: "Maciej W. Rozycki" To: Kumba Cc: libc-alpha@sources.redhat.com, linux-mips@linux-mips.org Subject: Re: Building GLIBC 2.3.4 on MIPS In-Reply-To: <421DE686.6040003@gentoo.org> Message-ID: References: <421BCF34.90308@jg555.com> <421BD616.4030101@avtrex.com> <421DE686.6040003@gentoo.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: 7339 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: 525 Lines: 15 On Thu, 24 Feb 2005, Kumba wrote: > The debian patch I referenced is what we require for glibc to generate a > proper syscalls.h for 2.4 kernels. Unknown on the 2.6 kernel front how that Well, glibc 2.3.4 works out of the box with 2.4. Perhaps you've had problems with an older revision. > patch affects things. I'll have to see if this patch affects/changes anything > for either headers version. It works for me with current 2.6. It requires a small obvious update due to changes to _MIPS_SIM macros. Maciej From ralf@linux-mips.org Fri Feb 25 10:09:14 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Feb 2005 10:09:29 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:26392 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 25 Feb 2005 10:09:14 +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 j1PA2mH5012851; Fri, 25 Feb 2005 10:02:49 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1PA2msi012845; Fri, 25 Feb 2005 10:02:48 GMT Date: Fri, 25 Feb 2005 10:02:47 +0000 From: Ralf Baechle To: Tsang-Ren Chang <690190029@s90.tku.edu.tw> Cc: linux-mips@linux-mips.org Subject: Re: ADM5120: Data bus error Message-ID: <20050225100247.GA10193@linux-mips.org> References: <421DF870.30708@s90.tku.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421DF870.30708@s90.tku.edu.tw> 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: 7340 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: 371 Lines: 11 On Thu, Feb 24, 2005 at 11:53:20PM +0800, Tsang-Ren Chang wrote: > Hi, > I'm porting linux-2.4.27 on adm5120 (MIPS 4Kc core). > But when I copied /sbin/pppd , It crashed. In addition to what Maciej said I'd like to add that bus errors are often signalled asynchronously, so the machine state in a register dump very often has no relation to the actual problem. Ralf From macro@linux-mips.org Fri Feb 25 16:48:06 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Feb 2005 16:48:25 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:11027 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 25 Feb 2005 16:48:06 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 723ABE1C84 for ; Fri, 25 Feb 2005 17:47:55 +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 28818-04 for ; Fri, 25 Feb 2005 17:47:55 +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 26E7DE1C6B for ; Fri, 25 Feb 2005 17:47:55 +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 j1PGlwuu027572 for ; Fri, 25 Feb 2005 17:47:59 +0100 Date: Fri, 25 Feb 2005 16:48:06 +0000 (GMT) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux In-Reply-To: <20050225131124Z8225457-1340+3673@linux-mips.org> Message-ID: References: <20050225131124Z8225457-1340+3673@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: 7341 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: 359 Lines: 13 On Fri, 25 Feb 2005 ths@linux-mips.org wrote: > Modified files: > arch/mips/mm : pg-sb1.c > > Log message: > Fix initialization. Unbreak the wait-for-completion loops. Code cleanup. Don't use a cast on IOADDR() -- it already returns "void *". The casts obfuscate code and make it difficult to spot incorrect use if the API ever changes. Maciej From macro@linux-mips.org Fri Feb 25 16:50:23 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Feb 2005 16:50:39 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:272 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 25 Feb 2005 16:50:23 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B6F68E1C84 for ; Fri, 25 Feb 2005 17:50: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 28818-09 for ; Fri, 25 Feb 2005 17:50: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 78F25E1C6B for ; Fri, 25 Feb 2005 17:50: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 j1PGoLEH027711 for ; Fri, 25 Feb 2005 17:50:21 +0100 Date: Fri, 25 Feb 2005 16:50:29 +0000 (GMT) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: Re: CVS Update@linux-mips.org: linux In-Reply-To: <20050225133831Z8225462-1340+3675@linux-mips.org> Message-ID: References: <20050225133831Z8225462-1340+3675@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: 7342 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: 210 Lines: 11 On Fri, 25 Feb 2005 ths@linux-mips.org wrote: > Modified files: > drivers/i2c/busses: i2c-sibyte.c > > Log message: > Fix 64bit builds. Well, these should actually be converted to ioremap()... Maciej From jpfoster@exterity.co.uk Fri Feb 25 17:30:02 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Feb 2005 17:30:18 +0000 (GMT) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:46361 "EHLO exterity.co.uk") by linux-mips.org with ESMTP id ; Fri, 25 Feb 2005 17:30:02 +0000 Received: from [192.168.0.85] ([192.168.0.85]) by exterity.co.uk with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 17:31:20 +0000 Subject: Re: Big Endian au1550 From: JP Foster To: linux-mips@linux-mips.org In-Reply-To: <20050224161542.74749.qmail@web203.biz.mail.re2.yahoo.com> References: <20050224161542.74749.qmail@web203.biz.mail.re2.yahoo.com> Content-Type: text/plain Date: Fri, 25 Feb 2005 17:29:56 +0000 Message-Id: <1109352597.2493.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2005 17:31:20.0953 (UTC) FILETIME=[D2084E90:01C51B5F] 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: 7343 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: 1631 Lines: 52 Yeah! Got it working withgcc 3.4.1. Trying again with latest linux-mips and it runs as far as borking that it can't find rootfs unknown block, but I assume that has to do with initramfs. --------- VFS: Cannot open root device "" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) --------- Do I need to disable ramdisk support for this? I think there were config options enabled that were causing the crash, pared it down to just the network and ethernet and serial console and it works, just had to patch this to get the compile working Index: mips/Kconfig =================================================================== RCS file: /home/cvs/linux/arch/mips/Kconfig,v retrieving revision 1.142 diff -r1.142 Kconfig 88a89 > select SYS_SUPPORTS_BIG_ENDIAN Index: mips/kernel/process.c =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/process.c,v retrieving revision 1.75 diff -r1.75 process.c 169,172c169,172 < gp[EF_CP0_EPC] = regs->cp0_epc; < gp[EF_CP0_BADVADDR] = regs->cp0_badvaddr; < gp[EF_CP0_STATUS] = regs->cp0_status; < gp[EF_CP0_CAUSE] = regs->cp0_cause; --- > // gp[EF_CP0_EPC] = regs->cp0_epc; > // gp[EF_CP0_BADVADDR] = regs->cp0_badvaddr; > // gp[EF_CP0_STATUS] = regs->cp0_status; > // gp[EF_CP0_CAUSE] = regs->cp0_cause; These must be compiler defined or something. Thanks everyone. The compiler was built from uclibc buildroot and set for mips1 -- jp.foster@exterity.co.uk Digital Simplicity From ichinoh@mb.neweb.ne.jp Sat Feb 26 14:37:04 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Feb 2005 14:38:35 +0000 (GMT) Received: from imfep06.dion.ne.jp ([IPv6:::ffff:210.174.120.157]:24142 "EHLO imfep06.dion.ne.jp") by linux-mips.org with ESMTP id ; Sat, 26 Feb 2005 14:37:04 +0000 Received: from [192.168.0.2] ([218.222.92.182]) by imfep06.dion.ne.jp (InterMail vM.4.01.03.31 201-229-121-131-20020322) with ESMTP id <20050226143651.MQJB23095.imfep06.dion.ne.jp@[192.168.0.2]>; Sat, 26 Feb 2005 23:36:51 +0900 Message-ID: <42208982.30201@mb.neweb.ne.jp> Date: Sat, 26 Feb 2005 23:36:50 +0900 From: Nyauyama User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Nyauyama Subject: Question DbAu1500 PCI Content-Type: text/plain; charset=ISO-2022-JP 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: 7344 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: ichinoh@mb.neweb.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 288 Lines: 13 Hello! I have a problem about DbAu1500's PCI. The PCI Configuration space of DbAu1500 is not seen by the boot loader that I made. However, if the PCI board is not installed in DbAu1500, the Configuration space of PCI HOST is seen. Have you ever encountered this phenomenon? Nyauyama From 690190029@s90.tku.edu.tw Sat Feb 26 18:07:08 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 26 Feb 2005 18:07:23 +0000 (GMT) Received: from msr35.hinet.net ([IPv6:::ffff:168.95.4.135]:6110 "EHLO msr35.hinet.net") by linux-mips.org with ESMTP id ; Sat, 26 Feb 2005 18:07:08 +0000 Received: from [192.168.186.100] (218-160-39-172.dynamic.hinet.net [218.160.39.172]) by msr35.hinet.net (8.9.3/8.9.3) with ESMTP id CAA20702 for ; Sun, 27 Feb 2005 02:07:02 +0800 (CST) Message-ID: <4220BA87.8070101@s90.tku.edu.tw> Date: Sun, 27 Feb 2005 02:05:59 +0800 From: Tsang-Ren Chang <690190029@s90.tku.edu.tw> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: ADM5120: Data bus error References: <421DF870.30708@s90.tku.edu.tw> <20050225100247.GA10193@linux-mips.org> In-Reply-To: <20050225100247.GA10193@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: <690190029@s90.tku.edu.tw> 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: 7345 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: 690190029@s90.tku.edu.tw Precedence: bulk X-list: linux-mips Content-Length: 543 Lines: 28 Ralf Baechle wrote: >On Thu, Feb 24, 2005 at 11:53:20PM +0800, Tsang-Ren Chang wrote: > > > >>Hi, >>I'm porting linux-2.4.27 on adm5120 (MIPS 4Kc core). >>But when I copied /sbin/pppd , It crashed. >> >> > >In addition to what Maciej said I'd like to add that bus errors are often >signalled asynchronously, so the machine state in a register dump very >often has no relation to the actual problem. > > Ralf > >. > > > Hi, I rebuilt the kernel with uncached option and the error disappeared. What does that mean? Thanks, T.R. Chang From ppopov@embeddedalley.com Sun Feb 27 22:03:52 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 27 Feb 2005 22:04:08 +0000 (GMT) Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:22882 "HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP id ; Sun, 27 Feb 2005 22:03:52 +0000 Received: from unknown (HELO ?10.2.2.69?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 27 Feb 2005 22:03:49 -0000 Message-ID: <4220F253.6060508@embeddedalley.com> Date: Sat, 26 Feb 2005 14:04:03 -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: Fixes to MTD flash driver on AMD Alchemy db1100 board References: <1108962105.6611.24.camel@SillyPuddy.localdomain> <1109052412.20045.6.camel@SillyPuddy.localdomain> <421ADE76.5020905@embeddedalley.com> <200502221632.53448.eckhardt@satorlaser.com> In-Reply-To: <200502221632.53448.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: 7346 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: 1321 Lines: 38 Ulrich Eckhardt wrote: > Pete Popov wrote: > >>Here is a 2.6 patch that gets rid of all the Au1x mapping files and >>replaces them with a single file. > > > Big step forward, this looks much cleaner and easier to maintain! > > Just a few nits: > > 1. mymtd = do_map_probe("cfi_probe", &alchemy_map); > > Doesn't this mean that the Alchemy flash driver depends on the CFI interface? > I also see that CONFIG_MTD_CFI is not set in the configfiles for some boards. > > 2. If above do_map_probe() returns NULL, the ioremap()ed memory is leaked. > Doesn't matter that much probably, but is trivial to fix. > > if (!mymtd) > { > iounmap( alchemy_map.virt); > return -ENXIO; > } > > 3. No need to cast the parameter to iounmap(), it should happily digest > whatever ioremap() returns. If that gives warnings, something different is > going wrong in between. ;) Thanks, I took care of all this. I removed the multiple drivers in favor of the single, simplied driver. I pushed the updates in linux-mips head, and the mtd community tree. To use these changes with linux-mips 2.4 branch, you have to patch-in the entire mtd tree. However, even then I had some compile problems that were not related to the changes I made, so I don't know if you can still use the latest mtd tree with a 2.4 kernel. Pete From pe1rxq@amsat.org Sun Feb 27 23:23:37 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 27 Feb 2005 23:23:53 +0000 (GMT) Received: from amsfep15-int.chello.nl ([IPv6:::ffff:213.46.243.28]:36939 "EHLO amsfep15-int.chello.nl") by linux-mips.org with ESMTP id ; Sun, 27 Feb 2005 23:23:37 +0000 Received: from [127.0.0.1] (really [62.195.248.222]) by amsfep15-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20050227232331.GNKX12698.amsfep15-int.chello.nl@[127.0.0.1]> for ; Mon, 28 Feb 2005 00:23:31 +0100 Message-ID: <422256A3.2030407@amsat.org> Date: Mon, 28 Feb 2005 00:24:19 +0100 From: Jeroen Vreeken User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: sparse and mips 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: 7347 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: pe1rxq@amsat.org Precedence: bulk X-list: linux-mips Content-Length: 3548 Lines: 74 Hi, I tried compiling my switch driver with sparse to see if I did some stupid casts and got a lot of warnings.... (attached below) Are others using sparse with mips kernels and getting the same? Or has nobody taken the time to fix it up? (The byteorder stuff should creap up everywhere or not?) Jeroen pe1rxq@laptop:~/edimax/linux-2.6.10-adm$ make vmlinuz C=1 CHK include/linux/version.h make[1]: `arch/mips/kernel/offset.s' is up to date. CHK include/asm-mips/offset.h make[1]: `arch/mips/kernel/reg.s' is up to date. CHK include/asm-mips/reg.h CHK include/linux/compile.h CHK usr/initramfs_list CHECK drivers/net/adm5120sw.c include/asm/byteorder.h:27:4: warning: "MIPS, but neither __MIPSEB__, nor __MIPSEL__???" include/linux/kernel.h:200:2: warning: "Please fix asm/byteorder.h" include/linux/aio_abi.h:59:2: warning: edit for your odd byteorder. include/linux/types.h:24:26: warning: Expected ; at end of declaration include/linux/types.h:24:26: warning: got nlink_t include/linux/types.h:64:26: warning: Expected ; at end of declaration include/linux/types.h:64:26: warning: got size_t include/linux/types.h:69:26: warning: Expected ; at end of declaration include/linux/types.h:69:26: warning: got ssize_t include/linux/types.h:74:28: warning: Expected ; at end of declaration include/linux/types.h:74:28: warning: got ptrdiff_t include/asm/bitops.h:75:9: warning: Expected ) after asm include/asm/bitops.h:75:9: warning: got __LL include/asm/bitops.h:83:9: warning: Expected ) after asm include/asm/bitops.h:83:9: warning: got __LL include/asm/bitops.h:135:9: warning: Expected ) after asm include/asm/bitops.h:135:9: warning: got __LL include/asm/bitops.h:143:9: warning: Expected ) after asm include/asm/bitops.h:143:9: warning: got __LL include/asm/bitops.h:194:9: warning: Expected ) after asm include/asm/bitops.h:194:9: warning: got __LL include/asm/bitops.h:205:9: warning: Expected ) after asm include/asm/bitops.h:205:9: warning: got __LL include/asm/bitops.h:256:9: warning: Expected ) after asm include/asm/bitops.h:256:9: warning: got __LL include/asm/bitops.h:275:9: warning: Expected ) after asm include/asm/bitops.h:275:9: warning: got __LL include/asm/bitops.h:346:9: warning: Expected ) after asm include/asm/bitops.h:346:9: warning: got __LL include/asm/bitops.h:366:9: warning: Expected ) after asm include/asm/bitops.h:366:9: warning: got __LL include/asm/bitops.h:438:9: warning: Expected ) after asm include/asm/bitops.h:438:9: warning: got __LL include/asm/bitops.h:457:9: warning: Expected ) after asm include/asm/bitops.h:457:9: warning: got __LL include/linux/kernel.h:83:40: warning: Expected ) in function declarator include/linux/kernel.h:83:40: warning: got size include/linux/kernel.h:85:40: warning: Expected ) in function declarator include/linux/kernel.h:85:40: warning: got size include/linux/kernel.h:86:41: warning: Expected ) in function declarator include/linux/kernel.h:86:41: warning: got size include/linux/kernel.h:88:41: warning: Expected ) in function declarator include/linux/kernel.h:88:41: warning: got size include/asm/string.h:44:77: warning: Expected ) in function declarator include/asm/string.h:44:77: warning: got __n include/asm/string.h:48:11: warning: Expected ) in function declarator include/asm/string.h:48:11: warning: got == include/asm/string.h:48:3: warning: Trying to use reserved word 'if' as identifier make[2]: *** [drivers/net/adm5120sw.o] Error 139 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 From bprasad@CS.Arizona.EDU Mon Feb 28 00:28:59 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Feb 2005 00:29:14 +0000 (GMT) Received: from optima.cs.arizona.edu ([IPv6:::ffff:192.12.69.5]:2829 "EHLO optima.cs.arizona.edu") by linux-mips.org with ESMTP id ; Mon, 28 Feb 2005 00:28:59 +0000 Received: from lectura.CS.Arizona.EDU (lectura.cs.arizona.edu [192.12.69.186]) by optima.cs.arizona.edu (8.12.11/8.13.3) with ESMTP id j1S0Svfj027214 for ; Sun, 27 Feb 2005 17:28:57 -0700 (MST) (envelope-from bprasad@CS.Arizona.EDU) Date: Sun, 27 Feb 2005 17:28:57 -0700 (MST) From: Prasad Venkata Boddupalli To: linux-mips@linux-mips.org Subject: cross-compile toolchain for linux-mips64? 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: 7348 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: bprasad@CS.Arizona.EDU Precedence: bulk X-list: linux-mips Content-Length: 223 Lines: 9 Hi, 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? thanks, Prasad From ralf@linux-mips.org Mon Feb 28 12:13:46 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Feb 2005 12:14:01 +0000 (GMT) Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:8477 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 28 Feb 2005 12:13:46 +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 j1SCBMUE013116; Mon, 28 Feb 2005 12:11:22 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j1SCBKYD013115; Mon, 28 Feb 2005 12:11:20 GMT Date: Mon, 28 Feb 2005 12:11:20 +0000 From: Ralf Baechle To: Jeroen Vreeken Cc: linux-mips@linux-mips.org Subject: Re: sparse and mips Message-ID: <20050228121120.GA11719@linux-mips.org> References: <422256A3.2030407@amsat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422256A3.2030407@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: 7349 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: 869 Lines: 26 On Mon, Feb 28, 2005 at 12:24:19AM +0100, Jeroen Vreeken wrote: > I tried compiling my switch driver with sparse to see if I did some > stupid casts and got a lot of warnings.... (attached below) > Are others using sparse with mips kernels and getting the same? > Or has nobody taken the time to fix it up? > (The byteorder stuff should creap up everywhere or not?) Not to my knowledge. I always meant to as a preventive maintenance meassure but somehow there was always something more important to do ... > include/asm/byteorder.h:27:4: warning: "MIPS, but neither __MIPSEB__, > nor __MIPSEL__???" > include/linux/kernel.h:200:2: warning: "Please fix asm/byteorder.h" A result of sparse not knowing about MIPS yet. > include/linux/aio_abi.h:59:2: warning: edit for your odd byteorder. Same. The others don't really make sense at the first look. 73, Ralf From geert@linux-m68k.org Mon Feb 28 12:37:19 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Feb 2005 12:37:35 +0000 (GMT) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:39120 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Mon, 28 Feb 2005 12:37:19 +0000 Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j1SCTeGU000746; Mon, 28 Feb 2005 13:29:40 +0100 (MET) Date: Mon, 28 Feb 2005 13:29:35 +0100 (CET) From: Geert Uytterhoeven To: Ralf Baechle cc: Jeroen Vreeken , Linux/MIPS Development Subject: Re: sparse and mips In-Reply-To: <20050228121120.GA11719@linux-mips.org> Message-ID: References: <422256A3.2030407@amsat.org> <20050228121120.GA11719@linux-mips.org> 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: 7350 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: geert@linux-m68k.org Precedence: bulk X-list: linux-mips Content-Length: 1666 Lines: 42 On Mon, 28 Feb 2005, Ralf Baechle wrote: > On Mon, Feb 28, 2005 at 12:24:19AM +0100, Jeroen Vreeken wrote: > > I tried compiling my switch driver with sparse to see if I did some > > stupid casts and got a lot of warnings.... (attached below) > > Are others using sparse with mips kernels and getting the same? > > Or has nobody taken the time to fix it up? > > (The byteorder stuff should creap up everywhere or not?) > > Not to my knowledge. I always meant to as a preventive maintenance meassure > but somehow there was always something more important to do ... > > > include/asm/byteorder.h:27:4: warning: "MIPS, but neither __MIPSEB__, > > nor __MIPSEL__???" > > include/linux/kernel.h:200:2: warning: "Please fix asm/byteorder.h" > > A result of sparse not knowing about MIPS yet. > > > include/linux/aio_abi.h:59:2: warning: edit for your odd byteorder. > > Same. You're using 2.6.10? When I played with sparse on m68k (cross-compile environment), I had to make some modifications to arch/m68k/Makefile, to pass a few additional flags to sparse in case of cross-compilation. Later these changes were moved to the main Makefile, since they were valid for all architectures if cross-compilation was involved. So I suggest to take a look at CHECKFLAGS in the main Makefile of the latest version (2.6.11-rc5) first, and see whether it works there. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From pe1rxq@amsat.org Mon Feb 28 14:00:01 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Feb 2005 14:00:17 +0000 (GMT) Received: from amsfep14-int.chello.nl ([IPv6:::ffff:213.46.243.21]:42537 "EHLO amsfep14-int.chello.nl") by linux-mips.org with ESMTP id ; Mon, 28 Feb 2005 14:00:01 +0000 Received: from [127.0.0.1] (really [62.195.248.222]) by amsfep14-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20050228135953.CHVF1537.amsfep14-int.chello.nl@[127.0.0.1]>; Mon, 28 Feb 2005 14:59:53 +0100 Message-ID: <4223240C.4010207@amsat.org> Date: Mon, 28 Feb 2005 15:00:44 +0100 From: Jeroen Vreeken User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ralf Baechle , Linux/MIPS Development Subject: Re: sparse and mips References: <422256A3.2030407@amsat.org> <20050228121120.GA11719@linux-mips.org> In-Reply-To: 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: 7351 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: pe1rxq@amsat.org Precedence: bulk X-list: linux-mips Content-Length: 1068 Lines: 34 Geert Uytterhoeven wrote: >You're using 2.6.10? > >When I played with sparse on m68k (cross-compile environment), I had to make >some modifications to arch/m68k/Makefile, to pass a few additional flags to >sparse in case of cross-compilation. Later these changes were moved to the main >Makefile, since they were valid for all architectures if cross-compilation was >involved. > >So I suggest to take a look at CHECKFLAGS in the main Makefile of the latest >version (2.6.11-rc5) first, and see whether it works there. > > 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 else CHECKFLAGS += -D_MIPS_SZLONG=64 endif ifdef CONFIG_CPU_LITTLE_ENDIAN CHECKFLAGS += -D__MIPSEL__ else CHECKFLAGS += -D__MIPSEB__ endif Jeroen From macro@linux-mips.org Mon Feb 28 21:14:58 2005 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Feb 2005 21:15:15 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:48394 "EHLO pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 28 Feb 2005 21:14:58 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3F907F5A29 for ; Mon, 28 Feb 2005 22:14:51 +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 12618-09 for ; Mon, 28 Feb 2005 22:14:51 +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 DEF43E1C77 for ; Mon, 28 Feb 2005 22:14:50 +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 j1SLEq8U005674 for ; Mon, 28 Feb 2005 22:14:53 +0100 Date: Mon, 28 Feb 2005 21:15:02 +0000 (GMT) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: [announce] Cross GCC 4.0.0 packages available Message-ID: 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: 7352 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: 573 Lines: 14 Hello, I've updated my RPM package archive to include sources and binaries of GCC 4.0.0 hosted on i386-linux for the mipsel-linux and the mips64el-linux targets. The mipsel-linux complier includes all frontends, that is for Ada, C, C++, Fortran, Java and Objective-C. The mips64el-linux compiler includes only the C frontend. No native packages yet. Note the mips64el-linux toolchain includes local changes that make it produce (n)64 binaries by default. Packages are available at the usual location, i.e.: "ftp://ftp3.ds.pg.gda.pl/people/macro/". Maciej