Menu
▾
▴
linuxsh-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
| 2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
| 2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
| 2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
| 2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
| 2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
| 2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
| 2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
|
From: NIIBE Y. <gn...@m1...> - 2002-01-24 08:42:21
|
SUGIOKA Toshinobu wrote: > Here it is. Just a note. This is already included in upstream. -- |
|
From: SUGIOKA T. <su...@it...> - 2002-01-24 08:38:42
|
At 02:30 02/01/24 -0600, "M. R. Brown" <mr...@0x...> wrote: >* SUGIOKA Toshinobu <su...@it...> on Thu, Jan 24, 2002: > >> >> This problem seems to be related on struct return from shared library. >> It is not only c++ specific, but also occurs on c program. >> >> I have uploaded updated binutils RPM packages. Thanks Kojima-san for the patch. >> http://www.sh-linux.org/rpm/RPMS/i386/Laser5-6.4/binutils-sh-linux-2.11.2-4.i386.rpm >> http://www.sh-linux.org/rpm/RPMS/i386/RedHat7.1/binutils-sh-linux-2.11.2-4.i386.rpm >> http://www.sh-linux.org/rpm/SRPMS/binutils-2.11.2-4.src.rpm >> >> Please retry with them. >> > >Um, where is the patch itself? > Here it is. diff -ru binutils-2.11.2.org/bfd/elf32-sh.c binutils-2.11.2/bfd/elf32-sh.c --- binutils-2.11.2.org/bfd/elf32-sh.c Thu Jan 24 14:09:50 2002 +++ binutils-2.11.2/bfd/elf32-sh.c Thu Jan 24 14:12:29 2002 @@ -2107,6 +2107,106 @@ /* First entry in an absolute procedure linkage table look like this. */ +#if 1 +static const bfd_byte elf_sh_plt0_entry_be[PLT_ENTRY_SIZE] = +{ + 0xd0, 0x05, /* mov.l 2f,r0 */ + 0x60, 0x02, /* mov.l @r0,r0 */ + 0x2f, 0x06, /* mov.l r0,@-r15 */ + 0xd0, 0x03, /* mov.l 1f,r0 */ + 0x60, 0x02, /* mov.l @r0,r0 */ + 0x40, 0x2b, /* jmp @r0 */ + 0x60, 0xf6, /* mov.l @r15+,r0 */ + 0x00, 0x09, /* nop */ + 0x00, 0x09, /* nop */ + 0x00, 0x09, /* nop */ + 0, 0, 0, 0, /* 1: replaced with address of .got.plt + 8. */ + 0, 0, 0, 0, /* 2: replaced with address of .got.plt + 4. */ +}; + +static const bfd_byte elf_sh_plt0_entry_le[PLT_ENTRY_SIZE] = +{ + 0x05, 0xd0, /* mov.l 2f,r0 */ + 0x02, 0x60, /* mov.l @r0,r0 */ + 0x06, 0x2f, /* mov.l r0,@-r15 */ + 0x03, 0xd0, /* mov.l 1f,r0 */ + 0x02, 0x60, /* mov.l @r0,r0 */ + 0x2b, 0x40, /* jmp @r0 */ + 0xf6, 0x60, /* mov.l @r15+,r0 */ + 0x09, 0x00, /* nop */ + 0x09, 0x00, /* nop */ + 0x09, 0x00, /* nop */ + 0, 0, 0, 0, /* 1: replaced with address of .got.plt + 8. */ + 0, 0, 0, 0, /* 2: replaced with address of .got.plt + 4. */ +}; + +/* Sebsequent entries in an absolute procedure linkage table look like + this. */ + +static const bfd_byte elf_sh_plt_entry_be[PLT_ENTRY_SIZE] = +{ + 0xd0, 0x04, /* mov.l 1f,r0 */ + 0x60, 0x02, /* mov.l @r0,r0 */ + 0xd1, 0x02, /* mov.l 0f,r1 */ + 0x40, 0x2b, /* jmp @r0 */ + 0x60, 0x13, /* mov r1,r0 */ + 0xd1, 0x03, /* mov.l 2f,r1 */ + 0x40, 0x2b, /* jmp @r0 */ + 0x00, 0x09, /* nop */ + 0, 0, 0, 0, /* 0: replaced with address of .PLT0. */ + 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ + 0, 0, 0, 0, /* 2: replaced with offset into relocation table. */ +}; + +static const bfd_byte elf_sh_plt_entry_le[PLT_ENTRY_SIZE] = +{ + 0x04, 0xd0, /* mov.l 1f,r0 */ + 0x02, 0x60, /* mov.l @r0,r0 */ + 0x02, 0xd1, /* mov.l 0f,r1 */ + 0x2b, 0x40, /* jmp @r0 */ + 0x13, 0x60, /* mov r1,r0 */ + 0x03, 0xd1, /* mov.l 2f,r1 */ + 0x2b, 0x40, /* jmp @r0 */ + 0x09, 0x00, /* nop */ + 0, 0, 0, 0, /* 0: replaced with address of .PLT0. */ + 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ + 0, 0, 0, 0, /* 2: replaced with offset into relocation table. */ +}; + +/* Entries in a PIC procedure linkage table look like this. */ + +static const bfd_byte elf_sh_pic_plt_entry_be[PLT_ENTRY_SIZE] = +{ + 0xd0, 0x04, /* mov.l 1f,r0 */ + 0x00, 0xce, /* mov.l @(r0,r12),r0 */ + 0x40, 0x2b, /* jmp @r0 */ + 0x00, 0x09, /* nop */ + 0x50, 0xc2, /* mov.l @(8,r12),r0 */ + 0xd1, 0x03, /* mov.l 2f,r1 */ + 0x40, 0x2b, /* jmp @r0 */ + 0x50, 0xc1, /* mov.l @(4,r12),r0 */ + 0x00, 0x09, /* nop */ + 0x00, 0x09, /* nop */ + 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ + 0, 0, 0, 0 /* 2: replaced with offset into relocation table. */ +}; + +static const bfd_byte elf_sh_pic_plt_entry_le[PLT_ENTRY_SIZE] = +{ + 0x04, 0xd0, /* mov.l 1f,r0 */ + 0xce, 0x00, /* mov.l @(r0,r12),r0 */ + 0x2b, 0x40, /* jmp @r0 */ + 0x09, 0x00, /* nop */ + 0xc2, 0x50, /* mov.l @(8,r12),r0 */ + 0x03, 0xd1, /* mov.l 2f,r1 */ + 0x2b, 0x40, /* jmp @r0 */ + 0xc1, 0x50, /* mov.l @(4,r12),r0 */ + 0x09, 0x00, /* nop */ + 0x09, 0x00, /* nop */ + 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ + 0, 0, 0, 0 /* 2: replaced with offset into relocation table. */ +}; +#else static const bfd_byte elf_sh_plt0_entry_be[PLT_ENTRY_SIZE] = { 0xd0, 0x04, /* mov.l 1f,r0 */ @@ -2167,7 +2267,7 @@ 0x03, 0xd1, /* mov.l 2f,r1 */ 0x2b, 0x40, /* jmp @r0 */ 0x09, 0x00, /* nop */ - 0, 0, 0, 0, /* 0: replaced with address of .PLT. */ + 0, 0, 0, 0, /* 0: replaced with address of .PLT0. */ 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ 0, 0, 0, 0, /* 2: replaced with offset into relocation table. */ }; @@ -2180,8 +2280,8 @@ 0x00, 0xce, /* mov.l @(r0,r12),r0 */ 0x40, 0x2b, /* jmp @r0 */ 0x00, 0x09, /* nop */ - 0x50, 0xc2, /* 0: mov.l @(8,r12),r0 */ - 0x52, 0xc1, /* 1: mov.l @(4,r12),r2 */ + 0x50, 0xc2, /* mov.l @(8,r12),r0 */ + 0x52, 0xc1, /* mov.l @(4,r12),r2 */ 0xd1, 0x02, /* mov.l 2f,r1 */ 0x40, 0x2b, /* jmp @r0 */ 0xe0, 0x00, /* mov #0,r0 ! shows the type of PLT. */ @@ -2196,8 +2296,8 @@ 0xce, 0x00, /* mov.l @(r0,r12),r0 */ 0x2b, 0x40, /* jmp @r0 */ 0x09, 0x00, /* nop */ - 0xc2, 0x50, /* 0: mov.l @(8,r12),r0 */ - 0xc1, 0x52, /* 1: mov.l @(4,r12),r2 */ + 0xc2, 0x50, /* mov.l @(8,r12),r0 */ + 0xc1, 0x52, /* mov.l @(4,r12),r2 */ 0x02, 0xd1, /* mov.l 2f,r1 */ 0x2b, 0x40, /* jmp @r0 */ 0x00, 0xe0, /* mov #0,r0 ! shows the type of PLT. */ @@ -2205,6 +2305,7 @@ 0, 0, 0, 0, /* 1: replaced with address of this symbol in .got. */ 0, 0, 0, 0 /* 2: replaced with offset into relocation table. */ }; +#endif static const bfd_byte *elf_sh_plt0_entry; static const bfd_byte *elf_sh_plt_entry; --- 杉岡利信 |
|
From: M. R. B. <mr...@0x...> - 2002-01-24 08:30:21
|
* SUGIOKA Toshinobu <su...@it...> on Thu, Jan 24, 2002: >=20 > This problem seems to be related on struct return from shared library. > It is not only c++ specific, but also occurs on c program. >=20 > I have uploaded updated binutils RPM packages. Thanks Kojima-san for the = patch. > http://www.sh-linux.org/rpm/RPMS/i386/Laser5-6.4/binutils-sh-linux-2.11.2= -4.i386.rpm > http://www.sh-linux.org/rpm/RPMS/i386/RedHat7.1/binutils-sh-linux-2.11.2-= 4.i386.rpm > http://www.sh-linux.org/rpm/SRPMS/binutils-2.11.2-4.src.rpm >=20 > Please retry with them. >=20 Um, where is the patch itself? Thanks, M. R. |
|
From: SUGIOKA T. <su...@it...> - 2002-01-24 07:23:29
|
At 21:21 02/01/23 +0200, Matan <ma...@sv...> wrote: >On Wed, 23 Jan 2002, Jordan Pan wrote: > >> Again I still face problem in the C++ dynamic link. I follow the >> patch for GCC and the new glibc 2.2.5(pre) build for Qt/embedded. It >> seems the compilation stage is passed, but fail in the runtime. Same >> problem is cleared when we link as static. > > >Might this be related to a c++ dynamic link problem I see? > >The attached file shows a simple c++ program that works ok when linked >statically, but segfaults when linked dynamically. The dynamic version >does work correctly on x86 processor. This problem seems to be related on struct return from shared library. It is not only c++ specific, but also occurs on c program. I have uploaded updated binutils RPM packages. Thanks Kojima-san for the patch. http://www.sh-linux.org/rpm/RPMS/i386/Laser5-6.4/binutils-sh-linux-2.11.2-4.i386.rpm http://www.sh-linux.org/rpm/RPMS/i386/RedHat7.1/binutils-sh-linux-2.11.2-4.i386.rpm http://www.sh-linux.org/rpm/SRPMS/binutils-2.11.2-4.src.rpm Please retry with them. ---- SUGIOKA Toshinobu |
|
From: Matan <ma...@sv...> - 2002-01-23 19:22:33
|
On Wed, 23 Jan 2002, Jordan Pan wrote: > Again I still face problem in the C++ dynamic link. I follow the > patch for GCC and the new glibc 2.2.5(pre) build for Qt/embedded. It > seems the compilation stage is passed, but fail in the runtime. Same > problem is cleared when we link as static. Might this be related to a c++ dynamic link problem I see? The attached file shows a simple c++ program that works ok when linked statically, but segfaults when linked dynamically. The dynamic version does work correctly on x86 processor. -- Matan Ziv-Av. ma...@sv... |
|
From: SUGIOKA T. <su...@it...> - 2002-01-23 12:24:46
|
At 10:19 02/01/22 +0900, NIIBE Yutaka <gn...@m1...> wrote: >ftp://ftp.m17n.org/pub/linux-sh/testing/gcc-sh-linux_3.0.3-5.diff.gz > >This fixes an issues: > leaf function optimization (not push/pop PR) I have updated RPM packages with this patch. You can get latest cross development tools at http://www.sh-linux.org/rpm-index ---- SUGIOKA Toshinobu |
|
From: Jordan P. <jo...@hi...> - 2002-01-23 02:12:07
|
Hello, Again I still face problem in the C++ dynamic link. I follow the patch = for GCC and the new glibc 2.2.5(pre) build for Qt/embedded. It seems the = compilation stage is passed, but fail in the runtime. Same problem is = cleared when we link as static. Does anybody ever try to link Qt/embedded especially in dynamic link ? We are still trying to test GNUSHv0201 tool chain which we get it from = http://www.kpit.com/products/support.htm. I hope it can work fine. -----Original Message----- From: NIIBE Yutaka [mailto:gn...@m1...] Sent: Tuesday, January 22, 2002 9:20 AM To: lin...@m1...; lin...@li... Subject: [linux-sh:02119] New GCC patch ftp://ftp.m17n.org/pub/linux-sh/testing/gcc-sh-linux_3.0.3-5.diff.gz This fixes an issues: leaf function optimization (not push/pop PR) Tested sh3-linux and sh4-linux. Thanks to Sugioka-san, for the testing. =3D=3D=3D gcc Summary =3D=3D=3D # of expected passes 15289 # of expected failures 76 # of unsupported tests 52 "Perfect!", Chris would say. :-) I'm going to build/test/package glibc 2.2.5(pre), as it improve C99 and C++ issues. --=20 |
|
From: Stuart M. <stu...@st...> - 2002-01-22 16:39:53
|
Here's the details for the ST boards: > harp > CPU subtype ST40STB1 > CPU arch (sh3 or sh4) SH4 > Default load address 0x88000000 > Default RAM size 32M > overdrive > CPU subtype ST40STB1 > CPU arch (sh3 or sh4) SH4 > Default load address 0x88000000 > Default RAM size 32M and two new boards about to appear... -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
|
From: NIIBE Y. <gn...@m1...> - 2002-01-22 01:19:48
|
ftp://ftp.m17n.org/pub/linux-sh/testing/gcc-sh-linux_3.0.3-5.diff.gz This fixes an issues: leaf function optimization (not push/pop PR) Tested sh3-linux and sh4-linux. Thanks to Sugioka-san, for the testing. === gcc Summary === # of expected passes 15289 # of expected failures 76 # of unsupported tests 52 "Perfect!", Chris would say. :-) I'm going to build/test/package glibc 2.2.5(pre), as it improve C99 and C++ issues. -- |
|
From: M. R. B. <mr...@0x...> - 2002-01-21 20:45:51
|
* Pete LeMasters <pet...@st...> on Mon, Jan 21, 2002: >=20 > This is using the 3.0.3 GCC tools, and the 2.4.13-pre2 kernel distributio= n. >=20 > /opt/xgcc-sh-3.0.3/bin/sh-elf-strip: supported targets: elf32-sh elf32-shl > coff-sh coff-shl coff-sh-small coff-shl-small elf32-little elf32-big srec > symbolsrec tekhex binary ihex >=20 > So, the real questions are these; >=20 > 1. What is the correct m4 flag to use for SH4 boards with the 3.0.3 tools? > 2. If the -mno-implicit-fp is to be used, what do I need to recompile to = add > the elf32-sh-linux to the list of supported targets? (binutils??) > 3. If I should be using -m4-no-fpu, what is the correct way to avoid the > compilation errors from sh-sci.c? >=20 1. Update your kernel to something recent. Do not use the kernel/ tree from CVS, use linux/ and prepend "-r linux-2_4-branch" to pull in the 2.4 branch. Use linux/scripts/treelink.sh to symlink this tree on top of a full Linux tree from kernel.org - the version to grab is the version indicated by the AGAINST-2.4.x file, in this case 2.4.16. 2. Do not use sh-elf as the --target, it contains absolutely zero SH Linux support. Use sh-linux or sh4-linux instead (the latter defaults to little endian, SH4). 3. Recompile your entire toolchain. M. R. |
|
From: Pete L. <pet...@st...> - 2002-01-21 15:39:27
|
Hi all, I've recently built the 3.0.3 version of the GCC tools, and while trying to re-compile the kernel, I've run into some troubles. The first is that when I used -m4-nofpu flag, the compiler defined __sh3__, which caused some problems with sh_sci.cc sh-sci.c: In function `sci_init_pins_scif': sh-sci.c:242: `SCPCR' undeclared (first use in this function) sh-sci.c:242: (Each undeclared identifier is reported only once sh-sci.c:242: for each function it appears in.) sh-sci.c:257: `SCPDR' undeclared (first use in this function) sh-sci.c: At top level: sh-sci.c:60: warning: `sci_init_pins_sci' declared `static' but never defined sh-sci.c:265: warning: `sci_init_pins_irda' defined but not used make[3]: *** [sh-sci.o] Error 1 So I changed the CFLAGS in the arch/sh/Makefile to -m4 -mno-implicit-fp, and made clean and recompiled. In this configuration all the source compiles, but during the link step I get the message "target elf32-sh-linux not found". This is using the 3.0.3 GCC tools, and the 2.4.13-pre2 kernel distribution. /opt/xgcc-sh-3.0.3/bin/sh-elf-strip: supported targets: elf32-sh elf32-shl coff-sh coff-shl coff-sh-small coff-shl-small elf32-little elf32-big srec symbolsrec tekhex binary ihex So, the real questions are these; 1. What is the correct m4 flag to use for SH4 boards with the 3.0.3 tools? 2. If the -mno-implicit-fp is to be used, what do I need to recompile to add the elf32-sh-linux to the list of supported targets? (binutils??) 3. If I should be using -m4-no-fpu, what is the correct way to avoid the compilation errors from sh-sci.c? thanks for your time. -pete |
|
From: Masahiro A. <m-...@aa...> - 2002-01-21 11:32:23
|
Sorry for late reply, On Tue, 15 Jan 2002 17:21:45 -0800 Jeremy Siegel <js...@mv...> wrote: > Thanks for the note -- maybe I'd better use TMU2 instead? Or I can move RTLinux's to TMU2, if general feature which uses TMU1 is added to standard kernel. > Actually though, what mode do you run it in? If you're doing timestamps, > you're probably using it in a similar way (just free-running: no interrupts, > let it wrap 0->ffffffff) then we should be able to work it out so there's no > conflict. I believe I'm doing what you have described here inside RTLinux-sh. It's free-running timer. I wanted to get finer-grained timestamp to make the scheduler behave more precisely. As a matter of fact, I haven't spent much time on RTLinux-sh after I've put it on the server, and my memory is fading :-< > --Jeremy Siegel ================================= Masahiro ABE, A&D Co., Ltd. Japan |
|
From: Masahiro A. <m-...@aa...> - 2002-01-21 11:24:13
|
Here is what I can provide on our ADX system. On Sun, 20 Jan 2002 02:06:10 -0600 "M. R. Brown" <mr...@0x...> wrote: > CPU subtype > CPU arch (sh3 or sh4) > Default load address > Default RAM size CONFIG_SH_ADX=y CONFIG_CPU_SUBTYPE_SH7750=y CONFIG_CPU_SH4=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_MEMORY_START=08000000 About default RAM size, I'm in the process of expanding it to 64MByte (originally it was 32MByte). I'm doing some housekeeping job on kernel for ADX and not ready for providing defconfig-adx yet. Will do when I decide it's time. Thank you for your effort for coordinating various boards support under controlled structure. I may not always be able to catch up to the state of CVS (even I still haven't be able to move to new tool chain yet!), but will keep my eyes on the post and try to provide required info. Thanks to Niibe-san for providing some info of ADX before I can. BTW, I remember Niibe-san requested some kind of information about several boards (including ADX) for including it into Configure.help or some for kernel 2.5. I can't remember exactly what info I should provide. Niibe-san, or someone else, please let me know if you have found some request is still not fulfilled about ADX. ================================= Masahiro ABE, A&D Co., Ltd. Japan |
|
From: Jeremy S. <js...@mv...> - 2002-01-21 05:50:39
|
"M. R. Brown" wrote: > That's where you come in. All board maintainers or anyone who knows what > these boards are, please reply with the following: > > CPU subtype > CPU arch (sh3 or sh4) > Default load address > Default RAM size Niibe covered almost everything;-) but it seems worth pointing out that the SE7751 comes with 64M RAM soldered on, at location 0x0C000000 (as usual). [Isn't all of this set based on the config anyway?] --Jeremy Siegel |
|
From: Greg B. <gn...@al...> - 2002-01-21 03:57:16
|
Greg Banks wrote: > > "M. R. Brown" wrote: > > > > That's where you come in. All board maintainers or anyone who knows what > > these boards are, please reply with the following: > > > > CPU subtype > > CPU arch (sh3 or sh4) > > Default load address > > Default RAM size > > > > dmida > > Default RAM size is 32 MB I think I may need to clarify this: the memory size is not fixed at kernel compile time but probed by the bootloader at boot and passed to the kernel with the mem= option, in order to support the same kernel running on 32MB and 64MB boxes. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. |
|
From: NIIBE Y. <gn...@m1...> - 2002-01-20 23:52:29
|
M. R. Brown wrote: > BTW, are you tagging the last version before syncing to the next one? Plea= > se, > let's be diligent about this. Done for 2.5.1. -- |
|
From: M. R. B. <mr...@0x...> - 2002-01-20 18:26:26
|
* NIIBE Yutaka <gn...@m1...> on Sun, Jan 20, 2002: >=20 > > se/770x (7708 or 7709) >=20 > There's no 7708 version. We support 7709A version, 7709S version, > 7750 version, 7750S version. >=20 Ah. On first glance I missed the 7750 support, I'll check for it again a bit later. I'll probably seperate it from the 7709 so it's a bit cleaner. If you (or any other developers) see any problems with the restructuring as it stands please don't hesitate to let us know. Thanks for the info, M. R. |
|
From: Dustin M. <du...@se...> - 2002-01-20 16:34:16
|
Here is the Bigsur's default information. Dustin. > > That's where you come in. All board maintainers or anyone who knows what > these boards are, please reply with the following: > > CPU subtype > CPU arch (sh3 or sh4) > Default load address > Default RAM size > > This will help us clean up arch/sh/config.in and eliminate the chance that > someone builds a board with the wrong information. Boards: > > bigsur CONFIG_CPU_SUBTYPE_SH7751=y CONFIG_CPU_SH4=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_MEMORY_START=0c000000 CONFIG_MEMORY_SIZE=00400000 |
|
From: Dustin M. <du...@se...> - 2002-01-20 16:19:54
|
This was a mistake when I initially submitted the patch... It should be
BIGSUR_IRQ_LOW not MGATE_IRQ_LOW. Sorry for the confusion.
Dustin.
Index: arch/sh/kernel/setup_bigsur.c
===================================================================
RCS file:
/home/CVS-ext/projects/software/core/kernel/arch/sh/kernel/setup_bigsur.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 setup_bigsur.c
--- arch/sh/kernel/setup_bigsur.c 2001/07/23 17:50:54 1.1.1.2
+++ arch/sh/kernel/setup_bigsur.c 2001/12/14 15:54:11
@@ -64,7 +64,7 @@
unsigned long flags;
unsigned char mask;
unsigned int mask_port = ((irq - BIGSUR_IRQ_LOW)/8) ? BIGSUR_IRLMR1
: BIGSUR_IRLMR0;
- unsigned char bit = (1 << ((irq - MGATE_IRQ_LOW)%8) );
+ unsigned char bit = (1 << ((irq - BIGSUR_IRQ_LOW)%8) );
if(irq >= BIGSUR_IRQ_LOW && irq < BIGSUR_IRQ_HIGH) {
DPRINTK("Disable L1 IRQ %d\n", irq);
@@ -86,7 +86,7 @@
unsigned long flags;
unsigned char mask;
unsigned int mask_port = ((irq - BIGSUR_IRQ_LOW)/8) ? BIGSUR_IRLMR1
: BIGSUR_IRLMR0;
- unsigned char bit = (1 << ((irq - MGATE_IRQ_LOW)%8) );
+ unsigned char bit = (1 << ((irq - BIGSUR_IRQ_LOW)%8) );
if(irq >= BIGSUR_IRQ_LOW && irq < BIGSUR_IRQ_HIGH) {
DPRINTK("Enable L1 IRQ %d\n", irq);
-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of M. R. Brown
Sent: Sunday, January 20, 2002 12:24 AM
To: lin...@li...
Subject: [linuxsh-dev] BigSur undefined constant
Call me crazy, but shouldn't this be defined somewhere - "MGATE_IRQ_LOW"?
Has anyone built the BigSur in awhile?
From arch/sh/kernel/setup_bigsur.c, line 67:
unsigned char bit = (1 << ((irq - MGATE_IRQ_LOW)%8) );
M. R.
|
|
From: M. R. B. <mr...@0x...> - 2002-01-20 14:58:35
|
* NIIBE Yutaka <gn...@m1...> on Sun, Jan 20, 2002: >=20 > Sorry for my mistake. It is Makefile which is wrong. Current tree is > against 2.5.2, I've forgot to sync the Makefile. >=20 > I should have had the file AGAINST-2.5.2-pre10 and proceded to 2.5.2. Ah, ok, no problem, it just took me a few minutes to figure what was going on :). I could only get the tree working against 2.5.2 anyway, so I guess I should've looked closer than that. BTW, are you tagging the last version before syncing to the next one? Plea= se, let's be diligent about this. Thanks, M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2002-01-20 10:10:13
|
M. R. Brown wrote: > adx SH7750 > cat68701 SH7708 16MB memory, recent version has 32MB. > cqreek SH7750 16MB There is 7708 version, but that one should be use bareCPU instead of cqreek. > hp6xx/hp620 > hp6xx/hp680 > hp6xx/hp690 All are SH7709A. HP620 and HP680 have 16MB, while HP690 has 32MB. > se/770x (7708 or 7709) There's no 7708 version. We support 7709A version, 7709S version, 7750 version, 7750S version. 7709A(or S) version has 32MB RAM, which can be 64MB. 7750 (or S) version has 64MB RAM. There're 7709 version and 7729 version, which we don't have any support yet. > se/7751 7751 > sh2000 SH7709A 16MB memory, recent version has 32MB. -- |
|
From: NIIBE Y. <gn...@m1...> - 2002-01-20 10:03:29
|
M. R. Brown wrote: > For future reference, please update the AGAINST-* file agianst the *real* > kernel version that you've synced against. The Makefile shows you've > actually synced against 2.5.2-pre10 and not vanilla 2.5.2 as this AGAINST > file tricked me into believing. > > I've updated the AGAINST-2.5.2-pre10 file. Sorry for my mistake. It is Makefile which is wrong. Current tree is against 2.5.2, I've forgot to sync the Makefile. I should have had the file AGAINST-2.5.2-pre10 and proceded to 2.5.2. -- |
|
From: Greg B. <gn...@al...> - 2002-01-20 09:58:27
|
"M. R. Brown" wrote: > > That's where you come in. All board maintainers or anyone who knows what > these boards are, please reply with the following: > > CPU subtype > CPU arch (sh3 or sh4) > Default load address > Default RAM size > > dmida CONFIG_CPU_SUBTYPE_SH7750=y CONFIG_CPU_SH4=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_MEMORY_START=0c000000 Default RAM size is 32 MB Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. |
|
From: M. R. B. <mr...@0x...> - 2002-01-20 08:39:01
|
* M. R. Brown <mr...@0x...> on Sun, Jan 20, 2002: >=20 > That's where you come in. All board maintainers or anyone who knows what > these boards are, please reply with the following: >=20 Also, if you have a preferred .config with your board, send that along as well. Paul and I are collecting/generating default configs for each board, and placing them in arch/sh/configs/defconfig-<board>. Thanks, M. R. |
|
From: M. R. B. <mr...@0x...> - 2002-01-20 08:24:33
|
Call me crazy, but shouldn't this be defined somewhere - "MGATE_IRQ_LOW"?
Has anyone built the BigSur in awhile?
=46rom arch/sh/kernel/setup_bigsur.c, line 67:
unsigned char bit =3D (1 << ((irq - MGATE_IRQ_LOW)%8) );
M. R.
|
25 messages has been excluded from this view by a project administrator.
