You can subscribe to this list here.
2002 |
Jan
(3) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(18) |
Mar
(23) |
Apr
(60) |
May
(40) |
Jun
(28) |
Jul
(1) |
Aug
(11) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(3) |
Jun
(20) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Yoshinori S. <ys...@us...> - 2007-06-22 07:12:34
|
At Mon, 18 Jun 2007 11:16:56 +0530, Ashay Jaiswal wrote: > Hi All, > > I am new to uclinux and I want to know some basics for adding support for H8s/ > 2368F into uclinux kernel. > > Please let me know if there is any tutorial or what all files are required to > be modified for adding support for new chip into the uclinux kernel. > > Any help in this regard will be appreciated. File name depends on kernel version, but it is similar procedure. for 2.4.x 1. Adding the symbol of the target to arch/h8300/target_config.in and arch/h8300/Boards.mk 2. mkdir arch/h8300/platform/h8s/(target_name) 3. cp arch/h8300/platform/h8s/generic/* arch/h8300/platform/h8s/(target_name)/ 4. arch/h8300/platform/h8s/(target_name) you remodel to the one for target. for 2.6.x 1. Adding the symbol of the target to arch/h8300/Kconfig.cpu and arch/h8300/Makefile 2. After, it is the same as the procedure of 2.4.x Give detailed information hereby if not sure. > Thanks and Regards > > Ashay Jasiwal > -- Yoshinori Sato <ys...@us...> |
From: Ashay J. <Ash...@kp...> - 2007-06-18 05:49:41
|
Hi All, =20 I am new to uclinux and I want to know some basics for adding support for H8s/2368F into uclinux kernel. =20 Please let me know if there is any tutorial or what all files are required to be modified for adding support for new chip into the uclinux kernel.=20 =20 Any help in this regard will be appreciated. =20 Thanks and Regards Ashay Jasiwal |
From: <ad...@wi...> - 2006-05-11 16:02:48
|
このメールはHTMLメールです。 HTMLメール対応メーラーでご覧下さい。配信停止希望の方はメール下部をご覧ください。 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ───────────────────── 発行 VIP.Collection 驚愕のクオリティ!スーパーコピーウォッチ! ───────────────────── ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ VIP.Collection http://vip-c-market.net/ Super CopyAAA&Sクラス専門店 http://vip-c-market.com/ ───────────────────────────────────── ★あなたの知り合いが持っている高級腕時計は本当に本物ですか?(笑) 本物は高い!でも完璧に再現されたコピーなら驚きの価格で.... 勿論、すぐに偽物と分かるような粗悪なものは御座いません! ★ニュースや質屋を騒がせたスーパーコピーを各種取り揃えました。 数に限りがありますので、お早めにご注文下さい! 例をあげると.... ロレックスの完全デイトジャスト機能はオリジナル製品同等の動き! フランクミューラークレイジーアワーズの完全ジャンプ機能は圧巻! そこいらのコピー品とは明らかに一線を画しております! ★高級腕時計を身に着けると、女の子の視線まで変わります! ★サイト上でその質感を余す所無くご紹介しておりますので、 是非その違いを実感して下さい。 http://vip-c-market.net/ http://vip-c-market.com/ ┏━┓ ┏━┃各┃人気ブランドのスーパーコピー御座います! ━┓ ┃ ┗━┛ ┃ ◆ロレックス 〜〜〜☆ ┃ ◇デイトナ ◇サブマリーナ 〜〜〜☆ ┃ ◇エクスプローラー ◇デイトジャスト他.. 〜〜〜☆ ┃ ◆カルティエ 〜〜〜☆ ┃ ◇サントス ◇ロードスター他.. 〜〜〜☆ ┃ ◆フランクミューラー 〜〜〜☆ ┃ ◇クレイジーアワーズ ◇ベガス他.. 〜〜〜☆ ┃ ◆ブルガリ 〜〜〜☆ ┃ ◇ブルガリブルガリ ◇デイアゴノ等 〜〜〜☆ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ────────────────────────────────────── ◇配信対象について このメールマガジンは、提携無料一括投稿サイトからの無料投稿を ご利用いただいた方や、スピードくじ、もしくは懸賞サイトなどにに 応募された方々へご利用規程に基づいてお送りしています。 しかしながら、アドレス間違いやイタズラの可能性もありますので、 身に覚えのない方、このメールの配信をを不快または不要と思われる方は お手数ですが下記アドレス迄お送り下さいますようお願い申し上げます。 In an unnecessary delivery, even here is de...@vi... |
From: <ad...@ea...> - 2006-04-01 04:00:28
|
配信停止希望の方はメール下部をご覧ください。 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ───────────────────── 発行 VIP.Collection 驚愕のクオリティ!スーパーコピーウォッチ! ───────────────────── ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ VIP.Collection http://collect-vip.com/ Super CopyAAA&Sクラス専門店 http://collect-vip.net/ ───────────────────────────────────── ★あなたの知り合いが持っている高級腕時計は本当に本物ですか?(笑) 本物は高い!でも完璧に再現されたコピーなら驚きの価格で.... 勿論、すぐに偽物と分かるような粗悪なものは御座いません! ★ニュースや質屋を騒がせたスーパーコピーを各種取り揃えました。 数に限りがありますので、お早めにご注文下さい! 例をあげると.... ロレックスの完全デイトジャスト機能はオリジナル製品同等の動き! フランクミューラークレイジーアワーズの完全ジャンプ機能は圧巻! そこいらのコピー品とは明らかに一線を画しております! ★高級腕時計を身に着けると、女の子の視線まで変わります! ★サイト上でその質感を余す所無くご紹介しておりますので、 是非その違いを実感して下さい。 http://collect-vip.com/ http://collect-vip.net/ ┏━┓ ┏━┃各┃人気ブランドのスーパーコピー御座います! ━┓ ┃ ┗━┛ ┃ ◆ロレックス 〜〜〜☆ ┃ ◇デイトナ ◇サブマリーナ 〜〜〜☆ ┃ ◇エクスプローラー ◇デイトジャスト他.. 〜〜〜☆ ┃ ◆カルティエ 〜〜〜☆ ┃ ◇サントス ◇ロードスター他.. 〜〜〜☆ ┃ ◆フランクミューラー 〜〜〜☆ ┃ ◇クレイジーアワーズ ◇ベガス他.. 〜〜〜☆ ┃ ◆ブルガリ 〜〜〜☆ ┃ ◇ブルガリブルガリ ◇デイアゴノ等 〜〜〜☆ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ────────────────────────────────────── ◇配信対象について このメールマガジンは、提携無料一括投稿サイトからの無料投稿を ご利用いただいた方や、スピードくじ、もしくは懸賞サイトなどにに 応募された方々へご利用規程に基づいてお送りしています。 しかしながら、アドレス間違いやイタズラの可能性もありますので、 身に覚えのない方、このメールの配信をを不快または不要と思われる方は お手数ですが下記アドレス迄お送り下さいますようお願い申し上げます。 In an unnecessary delivery, even here is de...@ea... |
From: Martin S. <ms...@gm...> - 2006-02-12 16:01:36
|
Hi, I want to port the ucLinux from EDOSK2674 Board toe the H8S2373 controller (with a new hardware design). Need I the boot mode of the EDOSK2674 board? How big is the kernel (how many space need I in the flash and ram?)? Thank you for your infos. bye martin sauer |
From: <spe...@in...> - 2005-11-13 20:52:17
|
knCCuIKpgrWCooKvgseBY4ypgsSCrYLqgtyCt4KpgWOBSA0KaHR0cDovL3d3 dy5zdGFyc2l0ZS0wNDguY29tL3BjDQoNCo6EkYqO6ILJmEGXjYK1gsSBY5HS gsGCxILpgqmC54FjDQpodHRwOi8vd3d3LnN0YXJzaXRlLTA0OC5jb20vcGMv a2FucmkxLmh0bQ== |
From: Alan D. <al...@co...> - 2005-06-20 04:40:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I downloaded the current Snapgear ISO (3.1.1) to compile for the EDOSK2674. I am attempting to compile the 2.4.x kernel. After running xconfig to choose my platform and the default for it, I ran 'make dep' and 'make' The make fails with the following: ... make[4]: Entering directory `/home/alandd/Projects/H8/SnapGear/snapgear/uClibc/libc/stdio' h8300-elf-gcc -Wall -Wstrict-prototypes -Wno-trigraphs - -fno-strict-aliasing -Os -O2 -ms -mint32-fno-builtin -DEMBED - -I/home/alandd/Projects/H8/SnapGear/snapgear/lib/uClibc/include - -I/home/alandd/Projects/H8/SnapGear/snapgear -Dlinux -D__linux__ - -D__uClinux__ -Dunix - -I/home/alandd/Projects/H8/SnapGear/snapgear/linux-2.4.x/include - -ms -mint32 -fsigned-char -fno-builtin -nostdinc -D_LIBC - -I../../include -I. -I/usr/local/lib/gcc-lib/h8300-elf/3.2.2/include - -DNDEBUG -DL_scanf scanf.c -c -oscanf.o scanf.c:129:2: #error STRTOUIM conversion function is undefined! ... I found this hit on a search of the the error with a patch to the include/stdint.h. http://mailman.uclinux.org/pipermail/uclinux-dev/2004-April/025920.html But making the change described does not solve the problem. Rather than first spending a lot of time going through code, I thought I'd first ask if this is a known issue with a known solution. If not, I'll go through code. ;^) Any hints? Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCtkiu0VxxIfjPXe4RAjzmAJ4oRTitxRhtyY2XiMSz7PLw0kOXhwCghlXX 0uvyaW7OHoG07aqU+KRViNk= =88qP -----END PGP SIGNATURE----- |
From: Yoshinori S. <ys...@us...> - 2005-04-09 15:44:18
|
PIC binary support toolcain and uClinux-dist release. 1. toolchain http://uclinux-h8.oscj.net/files/documents/16/1/h8300-linux-elf.tar.gz (linux + glibc2.2) include - gcc-3.4.3 with pic support patch - binutils-2.15 with pic support patch - elf2flt CVS Head Original pic support patch made by Kazu Hitara. 2. uClinux-dist http://uclinux-h8.oscj.net/files/documents/16/2/uClinux-dist-h8300-20050409.tar.gz Caution too large (>100MByte) Based uClinux-dist CVS Head. changes. - gcc-3.4.3 build error fix. - fix uClibc build error. - shared config fix. -- Yoshinori Sato <ys...@us...> |
From: Yoshinori S. <ys...@us...> - 2005-02-15 16:38:19
|
I implemented KGDB experimentally. http://prdownloads.sourceforge.jp/uclinux-h8/13406/h8300-kgdb-2.4.diff.gz There is brief description. http://uclinux-h8.sourceforge.jp/kgdb.html -- Yoshinori Sato <ys...@us...> |
From: Yoshinori S. <ys...@us...> - 2004-09-08 16:17:08
|
At 06 Sep 2004 09:35:31 +0200, Aleix Badia i Bosch wrote: > Dear all, I've some problems executing uclinux (linux-2.6.7 + uclinux + > h8300 port) using gdb debugger. >=20 > It looks like if there's no kernel initialization problem: > - MTD initialization (RAM) > - FS (romfs) initialization > - console registration > - sys_open /dev/console >=20 > NOTE: I'm using rootimage from uclinux-h8.sourceforge.jp with some /dev > modifications >=20 > crw------- 1 root root 5, 1 gen 1 1970 console > crw------- 1 root root 4, 0 gen 1 1970 tty0 > crw------- 1 root root 4, 64 gen 1 1970 ttySC0 > crw------- 1 root root 4, 65 gen 1 1970 ttySC1 >=20 >=20 > but it fails (or at least it looks like it fail) as there's no ouput, > when trying to execute /bin/init, just like idle task?=BF. I'm not sure if > /bin/init is running but gdb can't trace that process that way, or if > there's really a problem on kernel execve (-> syscall). >=20 >=20 > .... > if (execute_command) > run_init_process(execute_command); >=20 > run_init_process("/sbin/init"); -> fails (OK rootimage->/bin/init) > run_init_process("/etc/init"); -> fails (OK rootimage->/bin/init) > run_init_process("/bin/init"); -> OK (MTD OK, romfs OK) > run_init_process("/bin/sh"); >=20 > panic("No init found. Try passing init=3D option to kernel."); > .... >=20 >=20 > Breakpoint 5, sys_execve (name=3D0x5bb000 "/bin/init", argv=3D0x202004,=20 > envp=3D0x20202c, dummy=3D703605) at arch/h8300/kernel/process.c:256 > 256 error =3D do_execve(filename, argv, envp, regs); > 3: error =3D 6008832 > (gdb) n > 257 putname(filename); > 3: error =3D 0 > (gdb)=20 >=20 >=20 > GDB should show some init starting message (perhaps not the same as > busybox code below and rootimage are extracted from different busybox > versions) >=20 > extern int init_main(int argc, char **argv) > { >=20 > ..=20 > /* Hello world */ > message(MAYBE_CONSOLE | LOG, "init started: %s", > bb_msg_full_version); > ... >=20 > } >=20 > Perhaps bad busybox console initialization ? >=20 >=20 > I've no clear idea about gdb execution and the way console (struct > console) gdb_console, registred as gdb_con, is used by debugger; the > same with /dev/ttySC* or /dev/ttyS* >=20 >=20 > I just insert gdb vmlinux debugging output and attach .config file: >=20 > (gdb) target sim > SCI0 =3D /dev/pts/9 > Connected to the simulator. >=20 > (gdb) load > Loading section .vectors, size 0x100 vma 0x0 > Loading section .text, size 0xb4410 vma 0x100 > Loading section .data, size 0xfc40 vma 0x200000 > Loading section .romfs, size 0xc400 vma 0x218a98 > Start address 0x200 > Transfer rate: 6826624 bits in <1 sec. >=20 > (gdb) r > Starting program: /home/usuari/linux-2.6.7/vmlinux=20 > Linux version 2.6.7-uc0 (usuari@debian) (gcc version 3.1.1) #77 Mon Sep > 6 08:38:01 CEST 2004 >=20 >=20 > uClinux H8/300H > Target Hardware: generic > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > H8/300 series support by Yoshinori Sato <ys...@us...> > On node 0 totalpages: 1536 > DMA zone: 0 pages, LIFO batch:1 > Normal zone: 1536 pages, LIFO batch:1 > HighMem zone: 0 pages, LIFO batch:1 > Built 1 zonelists > Kernel command line: console=3DttySC0,38400n81 > PID hash table entries: 16 (order 4: 128 bytes) > Linux version 2.6.7-uc0 (usuari@debian) (gcc version 3.1.1) #77 Mon Sep > 6 08:38:01 CEST 2004 >=20 >=20 > uClinux H8/300H > Target Hardware: generic > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > H8/300 series support by Yoshinori Sato <ys...@us...> > On node 0 totalpages: 1536 > DMA zone: 0 pages, LIFO batch:1 > Normal zone: 1536 pages, LIFO batch:1 > HighMem zone: 0 pages, LIFO batch:1 > Built 1 zonelists > Kernel command line: console=3DttySC0,38400n81 > PID hash table entries: 16 (order 4: 128 bytes) > Memory available: 3860k/999k RAM, 0k/0k ROM (720k kernel code, 98k data) > Calibrating delay loop... 5.00 BogoMIPS > Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) > Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > Linux NoNET1.0 for Linux 2.6 > SuperH SCI(F) driver initialized > ttySC0 at MMIO 0xffffb0 (irq =3D 54) is a sci > ttySC1 at MMIO 0xffffb8 (irq =3D 58) is a sci > ttySC2 at MMIO 0xffffc0 (irq =3D 62) is a sci > Using anticipatory io scheduler > uclinux[mtd]: RAM probe address=3D0x218a98 size=3D0xd000 > Creating 1 MTD partitions on "RAM": > 0x00000000-0x0000d000 : "ROMfs" > uclinux[mtd]: set ROMfs to be root filesystem > VFS: Mounted root (romfs filesystem) readonly. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x0006c5a4 in L1a5 () at lib/radix-tree.c:756 > 756 } > (gdb)=20 >=20 >=20 > Regards, >=20 I cannot identify a problem in my environment. Will you identify it with new gcc? Can you take a root image if possible? --=20 Yoshinori Sato <ys...@us...> |
From: Aleix B. i B. <a....@ca...> - 2004-09-06 10:34:58
|
Dear all again, As it's explained in uclibc homepage http://www.uclibc.org/FAQ.html#compiling it should be necessary to use an h8300 specific uclibc toolchain to compile programs against it. I haven't found any h8300 uclibc toolchain builder in http://www.uclibc.org/cgi-bin/cvsweb/toolchain/ (or at least option in Makefile ARCH:=h8300). What methods could I use to obtain that toolchain ? there's any other way to link correctly againt uclibc without using that toolchain or previous versions wrapper ? NOTE: I've tried to do it manually having a look at *.mk and applying *.patch Regards -- Aleix Badia i Bosch a....@ca... |
From: Aleix B. i B. <a....@ca...> - 2004-09-06 07:35:36
|
Dear all, I've some problems executing uclinux (linux-2.6.7 + uclinux + h8300 port) using gdb debugger. It looks like if there's no kernel initialization problem: - MTD initialization (RAM) - FS (romfs) initialization - console registration - sys_open /dev/console NOTE: I'm using rootimage from uclinux-h8.sourceforge.jp with some /dev modifications crw------- 1 root root 5, 1 gen 1 1970 console crw------- 1 root root 4, 0 gen 1 1970 tty0 crw------- 1 root root 4, 64 gen 1 1970 ttySC0 crw------- 1 root root 4, 65 gen 1 1970 ttySC1 but it fails (or at least it looks like it fail) as there's no ouput, when trying to execute /bin/init, just like idle task?=BF. I'm not sure if /bin/init is running but gdb can't trace that process that way, or if there's really a problem on kernel execve (-> syscall). .... if (execute_command) run_init_process(execute_command); run_init_process("/sbin/init"); -> fails (OK rootimage->/bin/init) run_init_process("/etc/init"); -> fails (OK rootimage->/bin/init) run_init_process("/bin/init"); -> OK (MTD OK, romfs OK) run_init_process("/bin/sh"); panic("No init found. Try passing init=3D option to kernel."); .... Breakpoint 5, sys_execve (name=3D0x5bb000 "/bin/init", argv=3D0x202004,=20 envp=3D0x20202c, dummy=3D703605) at arch/h8300/kernel/process.c:256 256 error =3D do_execve(filename, argv, envp, regs); 3: error =3D 6008832 (gdb) n 257 putname(filename); 3: error =3D 0 (gdb)=20 GDB should show some init starting message (perhaps not the same as busybox code below and rootimage are extracted from different busybox versions) extern int init_main(int argc, char **argv) { ..=20 /* Hello world */ message(MAYBE_CONSOLE | LOG, "init started: %s", bb_msg_full_version); ... } Perhaps bad busybox console initialization ? I've no clear idea about gdb execution and the way console (struct console) gdb_console, registred as gdb_con, is used by debugger; the same with /dev/ttySC* or /dev/ttyS* I just insert gdb vmlinux debugging output and attach .config file: (gdb) target sim SCI0 =3D /dev/pts/9 Connected to the simulator. (gdb) load Loading section .vectors, size 0x100 vma 0x0 Loading section .text, size 0xb4410 vma 0x100 Loading section .data, size 0xfc40 vma 0x200000 Loading section .romfs, size 0xc400 vma 0x218a98 Start address 0x200 Transfer rate: 6826624 bits in <1 sec. (gdb) r Starting program: /home/usuari/linux-2.6.7/vmlinux=20 Linux version 2.6.7-uc0 (usuari@debian) (gcc version 3.1.1) #77 Mon Sep 6 08:38:01 CEST 2004 uClinux H8/300H Target Hardware: generic Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne H8/300 series support by Yoshinori Sato <ys...@us...> On node 0 totalpages: 1536 DMA zone: 0 pages, LIFO batch:1 Normal zone: 1536 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=3DttySC0,38400n81 PID hash table entries: 16 (order 4: 128 bytes) Linux version 2.6.7-uc0 (usuari@debian) (gcc version 3.1.1) #77 Mon Sep 6 08:38:01 CEST 2004 uClinux H8/300H Target Hardware: generic Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne H8/300 series support by Yoshinori Sato <ys...@us...> On node 0 totalpages: 1536 DMA zone: 0 pages, LIFO batch:1 Normal zone: 1536 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=3DttySC0,38400n81 PID hash table entries: 16 (order 4: 128 bytes) Memory available: 3860k/999k RAM, 0k/0k ROM (720k kernel code, 98k data) Calibrating delay loop... 5.00 BogoMIPS Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Linux NoNET1.0 for Linux 2.6 SuperH SCI(F) driver initialized ttySC0 at MMIO 0xffffb0 (irq =3D 54) is a sci ttySC1 at MMIO 0xffffb8 (irq =3D 58) is a sci ttySC2 at MMIO 0xffffc0 (irq =3D 62) is a sci Using anticipatory io scheduler uclinux[mtd]: RAM probe address=3D0x218a98 size=3D0xd000 Creating 1 MTD partitions on "RAM": 0x00000000-0x0000d000 : "ROMfs" uclinux[mtd]: set ROMfs to be root filesystem VFS: Mounted root (romfs filesystem) readonly. Program received signal SIGSEGV, Segmentation fault. 0x0006c5a4 in L1a5 () at lib/radix-tree.c:756 756 } (gdb)=20 Regards, --=20 Aleix Badia i Bosch a....@ca... |
From: Yoshinori S. <ys...@us...> - 2004-06-24 16:03:15
|
Release a patch corresponding to linux-2.6.7. Please apply the following patches to vanilla kernel. - h8300 depends parts http://prdownloads.sourceforge.jp/uclinux-h8/9933/linux-2.6.7-h8300.diff.gz - arch independ parts (linux-2.6.7-uc0.patch.gz subset) http://prdownloads.sourceforge.jp/uclinux-h8/9933/linux-2.6.7-uc0-h8300.patch Known problem NFS Root does not work. I mean that a problem occurs with a NFS client in kernel from the situation. Because I do not perform enough testing, there may be a problem in addition to this. -- Yoshinori Sato <ys...@us...> |
From: Yoshinori S. <ys...@us...> - 2004-06-16 14:11:55
|
At Tue, 15 Jun 2004 18:18:29 +0530, Rakesh Gupta, Noida wrote: > > which file system are using right now.. NFS seems to be a problem... > > I am getting following errors > (snip) Please apply a patch for mm/page_alloc.c of linux-2.6.6-uc0-patch.gz. -- Yoshinori Sato <ys...@us...> |
From: Yoshinori S. <ys...@us...> - 2004-06-16 14:11:51
|
At Tue, 8 Jun 2004 12:15:24 +0530 , Rakesh Gupta, Noida wrote: > > this is the output > > 0040f64e T _get_jiffies_64 > 00410314 T _sysctl_jiffies > 0041033c T _proc_dointvec_jiffies > 00410344 T _proc_dointvec_userhz_jiffies > 00410354 T _proc_doulongvec_ms_jiffies_minmax > 0052b11c D _printk_ratelimit_jiffies > 0052c27c D _wall_jiffies > 00542dd8 B _jiffies_64 > 00542ddc A _jiffies > > > I am sorry, I didnt get the point behind using mtd.. > and smc9194 was working in 2.4.x. what is wrong in this > version ? > Sorry. An answer becomes late. Because I think that it is a problem of handling of long long, please use gcc-3.4. Some corrections are added to smc9194 from a thing of 2.4.x. Do not work by some problems in driver of current 2.6.x-uc0. I am to make a patch for 2.6.7 that corrected. -- Yoshinori Sato <ys...@us...> |
From: Rakesh G. N. <ra...@no...> - 2004-06-15 12:51:08
|
which file system are using right now.. NFS seems to be a problem... I am getting following errors ============================================== Now booting linux kernel: Entry Address 0x00400000 Cmdline : console=ttySC2,38400 Linux version 2.6.7-rc2 (rakeshg@fr61) (gcc version 3.2.2) #26 Sun Jun 13 16:25: 59 IST 2004 uClinux H8S Target Hardware: EDOSK-2674 Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne H8/300 series support by Yoshinori Sato <ys...@us...> On node 0 totalpages: 3072 DMA zone: 0 pages, LIFO batch:1 Normal zone: 3072 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=ttySC2,38400 virtual vector at 0x00ffbe00 PID hash table entries: 16 (order 4: 128 bytes) Memory available: 6916k/1763k RAM, 0k/0k ROM (988k kernel code, 148k data) Calibrating delay loop... 7.24 BogoMIPS Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) NET: Registered protocol family 16 SuperH SCI(F) driver initialized ttySC0 at MMIO 0xffff78 (irq = 90) is a sci ttySC1 at MMIO 0xffff80 (irq = 94) is a sci ttySC2 at MMIO 0xffff88 (irq = 98) is a sci PPP generic driver version 2.4.2 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 512 bind 1024) IPv4 over IPv4 tunneling driver VFS: Cannot open root device "<NULL>" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) <0>Bad page state at __free_pages_ok (in process 'swapper', page 00538620) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bbdea0: 00bbdea0 00402ca4 0041eb68 004ec89f 00538620 0041efe2 0051dae8 00000002 00538600 00538600 00bbdec8 00bbdec8 0041fcc2 00000002 00017600 0041fd32 ffffffff 00538680 00423a14 00000002 00bffa7c 0051dae8 00000000 00bb0000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00538640) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bbdea0: 00bbdea0 00402ca4 0041eb68 004ec89f 00538640 0041efe2 0051dae8 00000002 00538600 00538600 00bbdec8 00bbdec8 0041fcc2 00000002 00017600 0041fd32 ffffffff 00538680 00423a14 00000002 00bffa7c 0051dae8 00000000 00bb0000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00538660) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bbdea0: 00bbdea0 00402ca4 0041eb68 004ec89f 00538660 0041efe2 0051dae8 00000002 00538600 00538600 00bbdec8 00bbdec8 0041fcc2 00000002 00017600 0041fd32 ffffffff 00538680 00423a14 00000002 00bffa7c 0051dae8 00000000 00bb0000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00538520) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bbdea0: 00bbdea0 00402ca4 0041eb68 004ec89f 00538520 0041efe2 0051dbd8 00000003 00538500 00538500 00bbdec8 00bbdec8 0041fcc2 00000003 00017500 0041fd32 ============================================== Any clues about things which are not yet complete in linux 2.6.7 and causing the problem ? Thanks, Rakesh -----Original Message----- From: Yoshinori Sato [mailto:ys...@us...] Sent: Monday, June 07, 2004 8:40 PM To: Rakesh Gupta, Noida Cc: H8-uclinux-port Subject: Re: [H8-uclinux-port] linux-2.6.5-uc0 H8/300 patch At Mon, 7 Jun 2004 16:25:00 +0530 , Rakesh Gupta, Noida wrote: > > while debugging, I found that jiffies is not updated due to some > reasons, that is why kernel was waiting at "Calibrating delay..." > > so in kernel/timer.c I added following... > -------------------------------------- > void do_timer(struct pt_regs *regs) > { > jiffies_64++; > jiffies = jiffies_64+4; /* this line added */ > ... > } > ---------- ? jiffies is equal to jiffies_64+4. How is it a result of "grep jiffies System.map"? > I am not very sure about the fix but the kernel moves ahead... > > though right now I am having some other problem in getting the NFS > root file system mounted... I am looking into this... Sorry. There does not seem to be smc9194 driver by completion. Please use mtd. -- Yoshinori Sato <ys...@us...> Disclaimer: This message and any attachment(s) contained here are information that is confidential,proprietary to HCL Technologies and its customers, privileged or otherwise protected by law.The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print,retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. |
From: Rakesh G. N. <ra...@no...> - 2004-06-08 06:40:16
|
this is the output 0040f64e T _get_jiffies_64 00410314 T _sysctl_jiffies 0041033c T _proc_dointvec_jiffies 00410344 T _proc_dointvec_userhz_jiffies 00410354 T _proc_doulongvec_ms_jiffies_minmax 0052b11c D _printk_ratelimit_jiffies 0052c27c D _wall_jiffies 00542dd8 B _jiffies_64 00542ddc A _jiffies I am sorry, I didnt get the point behind using mtd.. and smc9194 was working in 2.4.x. what is wrong in this version ? Rakesh -----Original Message----- From: Yoshinori Sato [mailto:ys...@us...] Sent: Monday, June 07, 2004 8:40 PM To: Rakesh Gupta, Noida Cc: H8-uclinux-port Subject: Re: [H8-uclinux-port] linux-2.6.5-uc0 H8/300 patch At Mon, 7 Jun 2004 16:25:00 +0530 , Rakesh Gupta, Noida wrote: > > while debugging, I found that jiffies is not updated due to some > reasons, that is why kernel was waiting at "Calibrating delay..." > > so in kernel/timer.c I added following... > -------------------------------------- > void do_timer(struct pt_regs *regs) > { > jiffies_64++; > jiffies = jiffies_64+4; /* this line added */ > ... > } > ---------- ? jiffies is equal to jiffies_64+4. How is it a result of "grep jiffies System.map"? > I am not very sure about the fix but the kernel moves ahead... > > though right now I am having some other problem in getting the NFS > root file system mounted... I am looking into this... Sorry. There does not seem to be smc9194 driver by completion. Please use mtd. -- Yoshinori Sato <ys...@us...> Disclaimer: This message and any attachment(s) contained here are information that is confidential,proprietary to HCL Technologies and its customers, privileged or otherwise protected by law.The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print,retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. |
From: Yoshinori S. <ys...@us...> - 2004-06-07 15:10:25
|
At Mon, 7 Jun 2004 16:25:00 +0530 , Rakesh Gupta, Noida wrote: > > while debugging, I found that jiffies is not updated due to some > reasons, that is why kernel was waiting at "Calibrating delay..." > > so in kernel/timer.c I added following... > -------------------------------------- > void do_timer(struct pt_regs *regs) > { > jiffies_64++; > jiffies = jiffies_64+4; /* this line added */ > ... > } > ---------- ? jiffies is equal to jiffies_64+4. How is it a result of "grep jiffies System.map"? > I am not very sure about the fix but the kernel moves ahead... > > though right now I am having some other problem in getting the NFS > root file system mounted... I am looking into this... Sorry. There does not seem to be smc9194 driver by completion. Please use mtd. -- Yoshinori Sato <ys...@us...> |
From: Rakesh G. N. <ra...@no...> - 2004-06-07 10:50:52
|
while debugging, I found that jiffies is not updated due to some reasons, that is why kernel was waiting at "Calibrating delay..." so in kernel/timer.c I added following... -------------------------------------- void do_timer(struct pt_regs *regs) { jiffies_64++; jiffies = jiffies_64+4; /* this line added */ ... } ---------- I am not very sure about the fix but the kernel moves ahead... though right now I am having some other problem in getting the NFS root file system mounted... I am looking into this... log for your reference.. ---------------------------------------------------------------------------- ----- RedBoot> load -r -b 0x400000 linux26.bin Raw file loaded 0x00400000-0x005422d7, assumed entry at 0x00400000 RedBoot> exec -c "console=ttySC2,38400 root=/dev/nfs rw nfsroot=192.168.14.79:/h 8sroot2 ip=192.168.14.89:192.168.14.79:192.168.14.2" 0x400000 Now booting linux kernel: Entry Address 0x00400000 Cmdline : console=ttySC2,38400 root=/dev/nfs rw nfsroot=192.168.14.79:/h8sroot2 ip=192.168.14.89:192.168.14.79:192.168.14.2 Linux version 2.6.7-rc2 (rakeshg@fr61) (gcc version 3.2.2) #23 Mon Jun 7 15:49:5 6 IST 2004 uClinux H8S Target Hardware: EDOSK-2674 Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne H8/300 series support by Yoshinori Sato <ys...@us...> On node 0 totalpages: 3072 DMA zone: 0 pages, LIFO batch:1 Normal zone: 3072 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=ttySC2,38400 root=/dev/nfs rw nfsroot=192.168.14.79 :/h8sroot2 ip=192.168.14.89:192.168.14.79:192.168.14.2 virtual vector at 0x00ffbe00 PID hash table entries: 16 (order 4: 128 bytes) Memory available: 6684k/1705k RAM, 0k/0k ROM (1177k kernel code, 193k data) Calibrating delay loop... 7.24 BogoMIPS Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) NET: Registered protocol family 16 SuperH SCI(F) driver initialized ttySC0 at MMIO 0xffff78 (irq = 90) is a sci ttySC1 at MMIO 0xffff80 (irq = 94) is a sci ttySC2 at MMIO 0xffff88 (irq = 98) is a sci RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize nbd: sizeof nbd_request needs to be 28 in order to work! PPP generic driver version 2.4.2 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 512 bind 1024) IPv4 over IPv4 tunneling driver IP-Config: No network devices available. Looking up port of RPC 100003/2 on 192.168.14.79 RPC: sendmsg returned error 101 portmap: RPC call returned error 101 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/1 on 192.168.14.79 RPC: sendmsg returned error 101 portmap: RPC call returned error 101 Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 101 mount: RPC call returned error 101 Root-NFS: Server returned error -101 while mounting /h8sroot2 VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0) Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0) <0>Bad page state at __free_pages_ok (in process 'swapper', page 00572720) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bc3ea0: 00bc3ea0 00405030 00420ef4 00518d3b 00572720 0042136e 00557ae8 00000002 00572700 00572700 00bc3ec8 00bc3ec8 0042204e 00000002 00017700 004220be ffffffff 00572780 00425da0 00000002 00bffa7c 00557ae8 00000000 00bb8000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00572740) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bc3ea0: 00bc3ea0 00405030 00420ef4 00518d3b 00572740 0042136e 00557ae8 00000002 00572700 00572700 00bc3ec8 00bc3ec8 0042204e 00000002 00017700 004220be ffffffff 00572780 00425da0 00000002 00bffa7c 00557ae8 00000000 00bb8000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00572760) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bc3ea0: 00bc3ea0 00405030 00420ef4 00518d3b 00572760 0042136e 00557ae8 00000002 00572700 00572700 00bc3ec8 00bc3ec8 0042204e 00000002 00017700 004220be ffffffff 00572780 00425da0 00000002 00bffa7c 00557ae8 00000000 00bb8000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00572520) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bc3ea0: 00bc3ea0 00405030 00420ef4 00518d3b 00572520 0042136e 00557bd8 00000003 00572500 00572500 00bc3ec8 00bc3ec8 0042204e 00000003 00017500 004220be ffffffff 00572600 00425da0 00000002 00bffa3c 00557bd8 00000000 00ba8000 Call Trace: Trying to fix it up, but a reboot is needed Bad page state at __free_pages_ok (in process 'swapper', page 00572540) flags:0x20000000 mapping:00000000 mapcount:0 count:1 Backtrace: Stack from 00bc3ea0: 00bc3ea0 00405030 00420ef4 00518d3b 00572540 0042136e 00557bd8 0000 ---------------------------------------------------------------------------- --- -----Original Message----- From: Yoshinori Sato [mailto:ys...@us...] Sent: Sunday, June 06, 2004 7:39 PM To: Paul Mundt; Rakesh Gupta, Noida; H8-uclinux-port Subject: Re: [H8-uclinux-port] linux-2.6.5-uc0 H8/300 patch At Sat, 5 Jun 2004 11:23:10 -0400, Paul Mundt wrote: > > On Sun, Jun 06, 2004 at 12:14:03AM +0900, Yoshinori Sato wrote: > > At Thu, 3 Jun 2004 21:38:21 +0530 , > > Rakesh Gupta, Noida wrote: > > > > > > Do we have "kgdb" support for EDOSK ? > > > > > > > > > > I think that do not need if use outside gdb-stub. > > But if there is a lot of request, I examine it. > > > > Because there is only one serial port, > > reconstruction of a board may come to require. > > > You can do kgdb with 1 serial port just fine, you just want to make sure > that you have a kgdb console setup to pass all of your console output > message to kgdb, which gdb can in turn handle (thus, gdb becomes your > console). Because input is not enacted, I am at a loss a little. > In SH we currently do this if you enable CONFIG_SH_KGDB_CONSOLE. Take > a look at arch/sh/kernel/kgdb_stub.c and the more interesting bits in > drivers/serial/sh-sci.c. There's no reason you shouldn't be able to do > this for h8300 as well. Become usable in 2.4.x. Header is had 2.6.x, but does not confirm action. Because I think that become usable if fix a little, I support. -- Yoshinori Sato <ys...@us...> Disclaimer: This message and any attachment(s) contained here are information that is confidential,proprietary to HCL Technologies and its customers, privileged or otherwise protected by law.The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print,retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. |
From: Paul M. <le...@li...> - 2004-06-06 20:30:12
|
On Sun, Jun 06, 2004 at 11:09:02PM +0900, Yoshinori Sato wrote: > > You can do kgdb with 1 serial port just fine, you just want to make sure > > that you have a kgdb console setup to pass all of your console output > > message to kgdb, which gdb can in turn handle (thus, gdb becomes your > > console). >=20 > Because input is not enacted, I am at a loss a little. > =20 Using gdb as a console only gives you a read-only console. You will still get console messages, but you don't have much of a method for interacting with the console. However, kgdb is only meant for debugging anyways, so this is still useful if you want to use kgdb on a board that only has a single serial port. In 2.6 there are other options as well for getting console message, such as using the netconsole, etc. although usually you can get the kgdb console initialized earlier on in the boot order if you need to debug something that happens before ethernet initialization, etc. |
From: Yoshinori S. <ys...@us...> - 2004-06-06 14:09:03
|
At Sat, 5 Jun 2004 11:23:10 -0400, Paul Mundt wrote: > > On Sun, Jun 06, 2004 at 12:14:03AM +0900, Yoshinori Sato wrote: > > At Thu, 3 Jun 2004 21:38:21 +0530 , > > Rakesh Gupta, Noida wrote: > > > > > > Do we have "kgdb" support for EDOSK ? > > > > > > > > > > I think that do not need if use outside gdb-stub. > > But if there is a lot of request, I examine it. > > > > Because there is only one serial port, > > reconstruction of a board may come to require. > > > You can do kgdb with 1 serial port just fine, you just want to make sure > that you have a kgdb console setup to pass all of your console output > message to kgdb, which gdb can in turn handle (thus, gdb becomes your > console). Because input is not enacted, I am at a loss a little. > In SH we currently do this if you enable CONFIG_SH_KGDB_CONSOLE. Take > a look at arch/sh/kernel/kgdb_stub.c and the more interesting bits in > drivers/serial/sh-sci.c. There's no reason you shouldn't be able to do > this for h8300 as well. Become usable in 2.4.x. Header is had 2.6.x, but does not confirm action. Because I think that become usable if fix a little, I support. -- Yoshinori Sato <ys...@us...> |
From: Paul M. <le...@li...> - 2004-06-05 15:23:36
|
On Sun, Jun 06, 2004 at 12:14:03AM +0900, Yoshinori Sato wrote: > At Thu, 3 Jun 2004 21:38:21 +0530 , > Rakesh Gupta, Noida wrote: > >=20 > > Do we have "kgdb" support for EDOSK ? > >=20 > >=20 >=20 > I think that do not need if use outside gdb-stub. > But if there is a lot of request, I examine it. >=20 > Because there is only one serial port,=20 > reconstruction of a board may come to require. >=20 You can do kgdb with 1 serial port just fine, you just want to make sure that you have a kgdb console setup to pass all of your console output message to kgdb, which gdb can in turn handle (thus, gdb becomes your console). In SH we currently do this if you enable CONFIG_SH_KGDB_CONSOLE. Take a look at arch/sh/kernel/kgdb_stub.c and the more interesting bits in drivers/serial/sh-sci.c. There's no reason you shouldn't be able to do this for h8300 as well. |
From: Yoshinori S. <ys...@us...> - 2004-06-05 15:14:03
|
At Thu, 3 Jun 2004 21:38:21 +0530 , Rakesh Gupta, Noida wrote: > > Do we have "kgdb" support for EDOSK ? > > I think that do not need if use outside gdb-stub. But if there is a lot of request, I examine it. Because there is only one serial port, reconstruction of a board may come to require. -- Yoshinori Sato <ys...@us...> |
From: Yoshinori S. <ys...@us...> - 2004-06-05 15:14:00
|
At Thu, 3 Jun 2004 14:03:35 +0530 , Rakesh Gupta, Noida wrote: > > After building the kernel I tried booting it.. but it stopped at calibrating > delay > > ------------------ > RedBoot> ip_address -l 192.168.14.89 -h 192.168.14.79 > IP: 192.168.14.89/255.255.255.0, Gateway: 0.0.0.0 > Default server: 192.168.14.79, DNS server IP: 0.0.0.0 > RedBoot> load -r -b 0x400000 linux26.bin > Raw file loaded 0x00400000-0x005422d7, assumed entry at 0x00400000 > RedBoot> exec -c "console=ttySC2,38400 root=/dev/nfs rw > nfsroot=192.168.14.79:/h > 8sroot2 ip=192.168.14.89:192.168.14.79:192.168.14.2" 0x400000 > Now booting linux kernel: > Entry Address 0x00400000 > Cmdline : console=ttySC2,38400 root=/dev/nfs rw > nfsroot=192.168.14.79:/h8sroot2 > ip=192.168.14.89:192.168.14.79:192.168.14.2 > Linux version 2.6.7-rc2 (rakeshg@fr61) (gcc version 3.2.2) #9 Wed Jun 2 > 19:59:41 > IST 2004 > > > uClinux H8S > Target Hardware: EDOSK-2674 > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > H8/300 series support by Yoshinori Sato <ys...@us...> > On node 0 totalpages: 3072 > DMA zone: 0 pages, LIFO batch:1 > Normal zone: 3072 pages, LIFO batch:1 > HighMem zone: 0 pages, LIFO batch:1 > Built 1 zonelists > Kernel command line: console=ttySC2,38400 root=/dev/nfs rw > nfsroot=192.168.14.79 > :/h8sroot2 ip=192.168.14.89:192.168.14.79:192.168.14.2 > virtual vector at 0x00ffbe00 > PID hash table entries: 16 (order 4: 128 bytes) > Memory available: 6684k/1705k RAM, 0k/0k ROM (1177k kernel code, 193k data) > Calibrating delay loop... > ------------------ > > Is there any change in the timer implementation of 2.6 ? > I am looking into this meanwhile if I can get some pointers that will be > helpful. > > Rakesh > I mean that stop in a place of timer interrupt. I do not change this part for a while. If RedBoot is usable, please show an execution result of following command. 1. x -b 0 -l 256 2. x -b 0xffbe00 -l 256 -- Yoshinori Sato <ys...@us...> |
From: Rakesh G. N. <ra...@no...> - 2004-06-03 16:03:20
|
Do we have "kgdb" support for EDOSK ? -----Original Message----- From: Yoshinori Sato [mailto:ys...@us...] Sent: Wednesday, June 02, 2004 10:02 PM To: Rakesh Gupta, Noida Cc: H8-uclinux-port Subject: Re: [H8-uclinux-port] linux-2.6.5-uc0 H8/300 patch At Wed, 2 Jun 2004 21:05:41 +0530 , Rakesh Gupta, Noida wrote: > > It was due to CONFIG_MODULE flag... > > that means MODULE support for EDOSK is still unavailable ? > > Rakesh > Kernel module is available. But correspondence of driver is not complete. -- Yoshinori Sato <ys...@us...> Disclaimer: This message and any attachment(s) contained here are information that is confidential,proprietary to HCL Technologies and its customers, privileged or otherwise protected by law.The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print,retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. |