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: Bryan R. <br...@ix...> - 2001-02-21 06:54:13
|
"M. R. Brown" wrote: > Hmm, my assumption (I could be wrong) was that SH4_BIT|SH3E_BIT weren't in > the the -m4-nofpu flag because all FP code generation is supposed to be > disabled. The question I had asked before was, why is this flag necessary > in the kernel (e.g. what does it matter if FP code generation is active or > not), but I hadn't gotten a response (I thought it was explained before > though). I guess what I'm saying is I think leaving those *_BITs off is > an internal gcc hack, so that it does sh4 insn scheduling, etc. but > doesn't do hardware floating-point, so that should probably stay off > (unless it's breaking something for you). Hmmm... Well, even with the patches I posted previously, I'm having trouble building the Linux kernel (2.4.1 out of LinuxSH CVS)... the problem is with our old friends __sdivsi3_i4, __udivsi3_i4, __udivsi3 and __sdivsi3. They are preventing linkage because they're undefined. Any idea how to fix this problem? I'm going to try not setting that SH4 bit, and hope that fixes it... Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: M. R. B. <ma...@uw...> - 2001-02-21 06:46:01
|
On Tue, 20 Feb 2001, Bryan Rittmeyer wrote:
> Hello,
>
> For anybody else as crazy (stupid?) as me that wants to try sh4 GNU CVS
> gcc, here's a patch to fix some compiler-defined symbols when -m4-nofpu
> is used. Currently, __sh3__ is defined by -m4-nofpu, but __sh4__ is not,
> which is causing the kernel compile to fail. Here's my fixup patch for
> gcc (for -rgcc-3_0-branch):
>
> --- gcc/config/sh/sh-old.h Thu Feb 15 09:16:52 2001
> +++ gcc/config/sh/sh.h Tue Feb 20 15:55:45 2001
> @@ -48,7 +48,7 @@
> %{m3e:-D__SH3E__} \
> %{m4-single-only:-D__SH4_SINGLE_ONLY__} \
> %{m4-single:-D__SH4_SINGLE__} \
> -%{m4-nofpu:-D__sh3__ -D__SH4_NOFPU__} \
> +%{m4-nofpu:-D__SH4__ -D__SH4_NOFPU__} \
> %{m4:-D__SH4__} \
>
I had been thinking about something like this too, I'll test your patch
with the -m4-nofpu flag on, thanks.
> %{!m1:%{!m2:%{!m3:%{!m3e:%{!m4:%{!m4-single:%{!m4-single-only:%{!m4-nofpu:-D__sh1__}}}}}}}}
> \
> %{mnomacsave:-D__NOMACSAVE__} \
> @@ -212,7 +212,7 @@
> {"4-single", TARGET_NONE, "" }, \
> {"4-single",
> SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT|FPU_SINGLE_BIT, ""
> },\
> {"4-nofpu", TARGET_NONE, "" }, \
> - {"4-nofpu", SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" },\
> + {"4-nofpu", SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT,
> "" },\
> {"4", TARGET_NONE, "" }, \
> {"4",
> SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" }, \
> {"b", -LITTLE_ENDIAN_BIT, "" }, \
>
Hmm, my assumption (I could be wrong) was that SH4_BIT|SH3E_BIT weren't in
the the -m4-nofpu flag because all FP code generation is supposed to be
disabled. The question I had asked before was, why is this flag necessary
in the kernel (e.g. what does it matter if FP code generation is active or
not), but I hadn't gotten a response (I thought it was explained before
though). I guess what I'm saying is I think leaving those *_BITs off is
an internal gcc hack, so that it does sh4 insn scheduling, etc. but
doesn't do hardware floating-point, so that should probably stay off
(unless it's breaking something for you).
> is anyone else using a cvs version of gcc with good results?
>
Yes, I admit I'm crazy to sync and build my gcc CVS nearly everyday, but
it's because different things seemed to break in kernel compilation from
day-to-day :). But the one I tried yesterday (20010220) worked perfectly.
> Also, is anyone using a new glibc (2.2, 2.2.1, 2.2.2) with the old
> (LinuxSH CVS) binutils and gcc? I've tried to do so, but get lots of
> undefined symbols and some conflicts with libgcc when trying to link
> (staticly or dynamically). but glibc itself builds without any error.
>
The only other issue I had with the 'sh-linux-gnu' target was that LinuxSH
decided to break ABI compatibility with the standard 'sh-unknown-elf'
flavors. Since I'm doing amatuer Dreamcast development, most of the tools
people out there are using are targeted to 'sh-elf' (old ABI), so I've had
to maintain two sets of tools. I have patches to create a new target,
'sh-sega-dreamcast' (which work), that currently uses sh-linux-gnu's ABI.
I was poking here and there tonite to see if it's possible in binutils and
gcc to conditionalize both ABIs and add a -mabi or -melf flag to sh.h, so
that I could use the same tools without breaking both environments. Does
anyone have any ideas? Are there any other archs/targets that do this?
Oh, by ABI I meant sh-linux-gnu doesn't require the leading underscore in
asm code while sh-elf does.
Hmm, could it be possible that the latest glibc is still using the old
ABI? If anything the undefined symbols are references to asm modules,
just pure speculation :).
M. R.
|
|
From: Bryan R. <br...@ix...> - 2001-02-21 05:30:38
|
Hi,
I've found this additional patch is necessary for proper cpp behavior:
--- gcc/config/sh/linux-old.h Tue Feb 20 21:26:51 2001
+++ gcc/config/sh/linux.h Tue Feb 20 21:24:40 2001
@@ -43,9 +43,9 @@
#define CPP_SPEC \
"%{mb:-D__BIG_ENDIAN__} \
%{!mb:-D__LITTLE_ENDIAN__} \
- %{m3e:-D__SH3E__} \
%{m4:-D__SH4__} \
- %{!m3e:%{!m4:-D__SH3__ -D__sh3__}} \
+ %{!m4:%{m4-nofpu:-D__SH4__ -D__SH4_NOFPU__}} \
+ %{!m4:%{!m4-nofpu:-D__SH3__ -D__sh3__}} \
%{fPIC:-D__PIC__ -D__pic__} \
%{fpic:-D__PIC__ -D__pic__} \
%{posix:-D_POSIX_SOURCE} \
@@ -59,11 +59,12 @@
#undef CC1_SPEC
#define CC1_SPEC \
- "-musermode %{!mb:-ml} %{!m3e:%{!m4:-m3}}"
+ "-musermode %{!mb:-ml} %{!m4:%{!m4-nofpu:-m3}}"
#undef CC1PLUS_SPEC
#define CC1PLUS_SPEC \
- "-musermode %{!mb:-ml} %{!m3e:%{!m4:-m3}}"
+ "-musermode %{!mb:-ml} %{!m4:%{!m4-nofpu:-m3}}"
+
#undef LINK_SPEC
#define LINK_SPEC \
@@ -71,7 +72,7 @@
%{shared:-shared} \
%{!static: \
%{rdynamic:-export-dynamic} \
- %{!dynamic-linker:-dynamic-linker /lib/ld.so.1} \
+ %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}
%{!rpath:-rpath /lib}} \
%{static:-static}"
if anyone else is interested, I am configuring GNU CVS gcc with:
../gcc/configure --target=sh-linux-gnu --prefix=/usr/local/sh
--enable-languages=c,c++ --disable-multilib
which seems to at least build correctly as of today.
Regards,
Bryan
--
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
|
|
From: Mitch D. <md...@po...> - 2001-02-21 03:03:17
|
Greg Banks wrote: > > I'm not sure its available anymore. This page > > http://www.hitachi.co.jp/Sicd/English/Products/micom/syuhen.htm > > has links for '63 and '65 docs but no '61. Perhaps someone has > an old copy? Hi Pawel, It seems I've found it. http://semiconductor.hitachi.com/products/pdf/h1cth005d1.pdf This was after a LOT of digging. (I would much rather Hitachi make their website and searching coherent and unified, rather than the fluffy facelifts it seems gets every two months or so...) Regards, Mitch. -- mailto:mj...@al... mailto:md...@po... |
|
From: Greg B. <gb...@po...> - 2001-02-21 02:34:30
|
Studencki Pawel wrote: > > hi, > > Greg, thanks for Your tips. Here my other doubts... > > > You need to get the User Manual for the HD64461 from Hitachi. > > In the '65 Manual, it implies in Section 8 Interrupt Controller that > > the IRQ0# from the '65 is level triggered, active low (which is what > > you'd expect for direct connection to our 7750). > > I was looking already for this manual, but I haven't found it...could > somebody tell me, where can I find it? Or perhaps could someone mail me this > file? I'm not sure its available anymore. This page http://www.hitachi.co.jp/Sicd/English/Products/micom/syuhen.htm has links for '63 and '65 docs but no '61. Perhaps someone has an old copy? > > [*] HD64461 PCMCIA enabler > > It's not a generic PCMCIA driver. It's a very simple hack which sets > > up port mappings for one specific set of cards in one specific box > > (an NE2000 network card and a CompactFlash memory card in an HP690). > > This is probably not what you want. > > but theoretical this could be working with my board, I need only to modify > some adresses and register values? Yes, and build the appropriate drivers into the kernel. But you have to be aware of the limitations of this solution: 1. you can't have any cards except those specific cards in the sockets, 2. you have to have the correct card in the correct socket, i.e. you can't swap them around, 3. the cards must be the default voltage handled by the socket, e.g. you can't mix 3.3V and 5V cards, 4. you can't insert or eject cards, 5. depending on how smart the driver is, you may not be able to boot the device without the cards inserted. I know IDE is clever enough to probe for devices, but I'm not so sure about the NE2K. All these are the reasons why Jesper Skov and I independently created PCMCIA Socket Services drivers, because they handle all these issues. However, as long as you're happy with these limitations the ENABLER solution will be OK for you. > I have a SanDisk PCMCIA flashdisk and perhaps (I don't have it yet) a ne2000 > compatible network card. In this case I don't need a PCMCIA socket service? Subject to the limitations above, no. If you need to support something other than the cards the ENABLER currently supports, try: 1. choose the cards you wish to support, 2. insert them into a Linux laptop's PCMCIA socket 3. use the dump_cis program to get the CIS data from the card 4. from that you can figure out a set of IO port and IRQ mappings which will keep the card happy. 5. hardcode those into the code > > If you want to be able to plug in various different types of cards, > > you need a proper PCMCIA Socket Services driver. AFAIK there > > isn't one > > for the 7709/64461 combination, but you might want to have a look at > > Jesper Skov's driver for the 7707, available at > > I understand, this is a second possibility. I have to hack PCMCIA enabler or > Jesper Skov's driver...I don't know which way is the most simple one...with > Jesper's solution I get probably more general stuff, but need to solve this > problem as quick as possible. If time to delivery is your major limiting factor, go for the quick ENABLER hack. > > For our PCMCIA support, we have the following compiled as modules: > > drivers/ide/ide-cs.o > drivers/ide/ide-disk.o > drivers/ide/ide-mod.o > drivers/ide/ide-probe-mod.o > drivers/net/8390.o > drivers/net/airo.o > drivers/net/ne.o > drivers/net/pcmcia/airo_cs.o > drivers/net/pcmcia/pcnet_cs.o > drivers/net/stnic.o > drivers/pcmcia/ds.o > drivers/pcmcia/hd64465_ss.o > drivers/pcmcia/pcmcia_core.o > > > The first 4 are necessary to mount flash cards as IDE disks. > > are they general? they should work, if I get working hd64462? The ide-cs module is for Card Services, and relies on a working PCMCIA socket driver (ide-cs handles negotiating ports and IRQs with the card). The others (ide-disk, ide-mod, ide-probe-mod) are generic and should work once you have port & IRQ mappings. > > > The last > > 3 are various PCMCIA drivers. > > PCMCIA driver with hd6446x support? For x=5. Untested on x!=5. Also, assumes SH4 in one place. And in another place, one particular voltage control chip of the two the 64465 supports. > So for SHx and HD6446x we have > companion chip support integrated with PCMCIA driver? These are modules, and > in arch/sh/kernel/setup_hd6446x.c are defined these early CF enable for > HP690? Um, I nearly understood that? > > The stuff in the middle is for supporting > > network cards. > > If I use ne2000, there should be no neeed to hack it, theoretical. Correct. Greg. -- These are my opinions not PPIs. |
|
From: Bryan R. <br...@ix...> - 2001-02-21 00:36:59
|
Hello,
For anybody else as crazy (stupid?) as me that wants to try sh4 GNU CVS
gcc, here's a patch to fix some compiler-defined symbols when -m4-nofpu
is used. Currently, __sh3__ is defined by -m4-nofpu, but __sh4__ is not,
which is causing the kernel compile to fail. Here's my fixup patch for
gcc (for -rgcc-3_0-branch):
--- gcc/config/sh/sh-old.h Thu Feb 15 09:16:52 2001
+++ gcc/config/sh/sh.h Tue Feb 20 15:55:45 2001
@@ -48,7 +48,7 @@
%{m3e:-D__SH3E__} \
%{m4-single-only:-D__SH4_SINGLE_ONLY__} \
%{m4-single:-D__SH4_SINGLE__} \
-%{m4-nofpu:-D__sh3__ -D__SH4_NOFPU__} \
+%{m4-nofpu:-D__SH4__ -D__SH4_NOFPU__} \
%{m4:-D__SH4__} \
%{!m1:%{!m2:%{!m3:%{!m3e:%{!m4:%{!m4-single:%{!m4-single-only:%{!m4-nofpu:-D__sh1__}}}}}}}}
\
%{mnomacsave:-D__NOMACSAVE__} \
@@ -212,7 +212,7 @@
{"4-single", TARGET_NONE, "" }, \
{"4-single",
SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT|FPU_SINGLE_BIT, ""
},\
{"4-nofpu", TARGET_NONE, "" }, \
- {"4-nofpu", SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" },\
+ {"4-nofpu", SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT,
"" },\
{"4", TARGET_NONE, "" }, \
{"4",
SH4_BIT|SH3E_BIT|SH3_BIT|SH2_BIT|SH1_BIT|HARD_SH4_BIT, "" }, \
{"b", -LITTLE_ENDIAN_BIT, "" }, \
is anyone else using a cvs version of gcc with good results?
Also, is anyone using a new glibc (2.2, 2.2.1, 2.2.2) with the old
(LinuxSH CVS) binutils and gcc? I've tried to do so, but get lots of
undefined symbols and some conflicts with libgcc when trying to link
(staticly or dynamically). but glibc itself builds without any error.
Regards,
Bryan
--
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
|
|
From: Studencki P. <Paw...@er...> - 2001-02-20 12:04:16
|
hi, Greg, thanks for Your tips. Here my other doubts... > You need to get the User Manual for the HD64461 from Hitachi. > In the '65 Manual, it implies in Section 8 Interrupt Controller that > the IRQ0# from the '65 is level triggered, active low (which is what > you'd expect for direct connection to our 7750). I was looking already for this manual, but I haven't found it...could somebody tell me, where can I find it? Or perhaps could someone mail me this file? > [*] HD64461 PCMCIA enabler > It's not a generic PCMCIA driver. It's a very simple hack which sets > up port mappings for one specific set of cards in one specific box > (an NE2000 network card and a CompactFlash memory card in an HP690). > This is probably not what you want. but theoretical this could be working with my board, I need only to modify some adresses and register values? I have a SanDisk PCMCIA flashdisk and perhaps (I don't have it yet) a ne2000 compatible network card. In this case I don't need a PCMCIA socket service? > If you want to be able to plug in various different types of cards, > you need a proper PCMCIA Socket Services driver. AFAIK there > isn't one > for the 7709/64461 combination, but you might want to have a look at > Jesper Skov's driver for the 7707, available at I understand, this is a second possibility. I have to hack PCMCIA enabler or Jesper Skov's driver...I don't know which way is the most simple one...with Jesper's solution I get probably more general stuff, but need to solve this problem as quick as possible. > For our PCMCIA support, we have the following compiled as modules: drivers/ide/ide-cs.o drivers/ide/ide-disk.o drivers/ide/ide-mod.o drivers/ide/ide-probe-mod.o drivers/net/8390.o drivers/net/airo.o drivers/net/ne.o drivers/net/pcmcia/airo_cs.o drivers/net/pcmcia/pcnet_cs.o drivers/net/stnic.o drivers/pcmcia/ds.o drivers/pcmcia/hd64465_ss.o drivers/pcmcia/pcmcia_core.o > The first 4 are necessary to mount flash cards as IDE disks. are they general? they should work, if I get working hd64462? > The last > 3 are various PCMCIA drivers. PCMCIA driver with hd6446x support? So for SHx and HD6446x we have companion chip support integrated with PCMCIA driver? These are modules, and in arch/sh/kernel/setup_hd6446x.c are defined these early CF enable for HP690? > The stuff in the middle is for supporting > network cards. If I use ne2000, there should be no neeed to hack it, theoretical. regards Pawel |
|
From: kaz K. <kk...@rr...> - 2001-02-20 07:25:22
|
Hi, Studencki Pawel <Paw...@er...> wrote: > Has somebody any ideas what could it be? I suppose, I'm using inproper > source files for a new toolchain, but I'm not sure and I don't know which > sources are correct. I have no idea, but it must be a compiler problem. Basically the current stable compiler for SH is 20001120 version of gcc-2.9.7 + patches. You can get them from http://www.m17n.org/linux-sh/. > Is it possible to use glibc-2.2.1 or 2.2.2 with other patches? What would > you recommend? Yes. I recommend glibc-2.2.2. It doesn't need any patches, as I know. Regards, kaz |
|
From: NIIBE Y. <gn...@m1...> - 2001-02-20 01:47:25
|
yos...@hi... wrote:
> Here is the register map for MS7751SE01. / yoshii
>
> /*
> Address Name Initial-val
> [bit] Signal
> ...
> */
>
> h'1b000000 ILCRA h'FEBA
> [15:12] ~SLOT_IRQ8
> [11:8] ~SLOT_IRQ7
> [7:4] ~SLOT_IRQ6
> [3:0] ~SLOT_IRQ5
I have to say that this is bad design. It seems that hardware
designer just thinks that "supporting interrupt priority". This works
well on limited use, but doesn't scale (in terms of number of kinds of
interrupts) well, and not general enough. Think about the case: we
have more than fifteen kinds of interrupt sources.
Supporting interrupt priority in hardware is not important. Most
important thing is to distinguish the souce of interrupts and the
feature of masking the interrupt souce independently. The design
would be:
Supports up to 32 interrupt sources
Interrupt source register
31..0
Interrupt mask register
31..0
Output:
INT_OUT = (INT_31 & INT_MASK_31) | (INT_30 & INT_MASK_30)
| ... | (INT_0 & INT_MASK_0)
If we have this mechanism, we easily can emulate the "interrupt
priority" scheme. For example, if we need to stop handling INT3..INT0
while handling INT4, just mask INT4..INT0 while getting INT4. And
it's more, we can implement other scheme.
In short:
Supporting interrupt priority in hardware is useless.
Do support generic one in hardware, software is more
suitable to implement good scheme.
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-02-20 01:01:22
|
Stuart Menefy wrote:
> Yes, I saw the same behaviour, both on the SH7750 and the ST40STB1.
> In fact as part of the changes I checked in for the STB1 boards was
> a 'fix' to rtc.c to handle this. At the moment it is unconditional, but
> if it doesn't occur on SH3 parts, then it sounds like we need to make it
> conditional as you suggest.
Thanks for the confirmation.
I've looked your change. On SH7708S and SH7709A, we don't need the
0x40 which you introduced. RTC(s) on those work well.
Next, we have two issues (on SH-4):
(1) Setting RTC, we restart RCR2, then R64CNT is reset to 0x00.
This means after 0.5 sec, we will see count up. Say, we set
23:59:00. On SH-3, 1 sec later, it goes 23:59:01, while 0.5
sec later on SH-4. I think we need to handle this issue for
SH-4.
(2) The value is not reliable.
On SH-3, as long as we check CF-flag of RCR1, we can get the
value reliably. However, when we read the value 0x40 on SH-4,
we can't rely on the CF-flag and the value of RSECCNT (etc.).
There's the case that the "carry" doesn't propagate to RSECCNT
and we read wrong value with no set of CF-flag. Say, we read
R64CNT=0x40, RSECCNT=0x00, CF=0. The right value may be
RSECCNT=0x01 or 0x00. There's no way to distingush the case.
Possible work around is when we read 0x40, we stay there until
we see 0x41... That sound quite bad for me.
> What's the difference between the SH7750 and SH7750S? That's a new one
> on me!
I don't see the difference in terms of software. Perhaps, hardware
refinement.
--
|
|
From: Greg B. <gb...@po...> - 2001-02-20 00:55:38
|
Studencki Pawel wrote: > > Hello, Hi Pawel, > I have some questions about "how do I get my PCMCIA devices working with > SH7709" :), especially with HD64461 companion chip. I'm not familiar with the '61 but I have worked with its brother the HD64465. > 1) My hd64461 is connected to pin INT0 of SH7709, so I've chosen interrupt > 0: > (0) HD64461 IRQ. > What other options do I have to modify? I mean, hardcoded options? > For example in function setup_hd64461, value for INTC_ICR1 has been set. In > this case (int 0) I have to set properly first 2 bits (mainly) of this > register (how can I determine kind of interrupt, falling or rising edge, low > level?) You need to get the User Manual for the HD64461 from Hitachi. In the '65 Manual, it implies in Section 8 Interrupt Controller that the IRQ0# from the '65 is level triggered, active low (which is what you'd expect for direct connection to our 7750). > 2) > [*] HD64461 PCMCIA enabler > What does this option mean? Is this enabling of HD64461? Do I need pcmcia > driver? It's not a generic PCMCIA driver. It's a very simple hack which sets up port mappings for one specific set of cards in one specific box (an NE2000 network card and a CompactFlash memory card in an HP690). This is probably not what you want. If you want to be able to plug in various different types of cards, you need a proper PCMCIA Socket Services driver. AFAIK there isn't one for the 7709/64461 combination, but you might want to have a look at Jesper Skov's driver for the 7707, available at http://sourceforge.net/patch/?func=detailpatch&patch_id=101171&group_id=2682 or my driver for the 7750/64465, which is drivers/pcmcia/hd64465_ss.c in 2.4.0-ac3. In either case you will need to modify the driver. > 3) > <*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support > and other options... > Should I compile this as a module? I thougth, I have to compile first the > pcmcia driver as module and install it with insmod. Only after that I can > use any pcmcia devices: card flashes or network adaptars. Does it look like: > > kernel > ---------------------------- > hd64461 > ---------------------------- > pcmcia > --------------------------- > Flash | network | ... > > I would be grateful for any tips and explanations of these problems (what > hardware aspects are exceptionally important? ) For our PCMCIA support, we have the following compiled as modules: drivers/ide/ide-cs.o drivers/ide/ide-disk.o drivers/ide/ide-mod.o drivers/ide/ide-probe-mod.o drivers/net/8390.o drivers/net/airo.o drivers/net/ne.o drivers/net/pcmcia/airo_cs.o drivers/net/pcmcia/pcnet_cs.o drivers/net/stnic.o drivers/pcmcia/ds.o drivers/pcmcia/hd64465_ss.o drivers/pcmcia/pcmcia_core.o The first 4 are necessary to mount flash cards as IDE disks. The last 3 are various PCMCIA drivers. The stuff in the middle is for supporting network cards. For IDE flash cards, you will probably want to choose: m Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support m Include IDE/ATA-2 DISK support m PCMCIA IDE support In theory, all this stuff can be built into the kernel, but we've always used modules. Greg. -- These are my opinions not PPIs. |
|
From: Studencki P. <Paw...@er...> - 2001-02-19 15:13:32
|
Hello, I have some questions about "how do I get my PCMCIA devices working with SH7709" :), especially with HD64461 companion chip. 1) My hd64461 is connected to pin INT0 of SH7709, so I've chosen interrupt 0: (0) HD64461 IRQ. What other options do I have to modify? I mean, hardcoded options? For example in function setup_hd64461, value for INTC_ICR1 has been set. In this case (int 0) I have to set properly first 2 bits (mainly) of this register (how can I determine kind of interrupt, falling or rising edge, low level?) 2) [*] HD64461 PCMCIA enabler What does this option mean? Is this enabling of HD64461? Do I need pcmcia driver? 3) <*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support and other options... Should I compile this as a module? I thougth, I have to compile first the pcmcia driver as module and install it with insmod. Only after that I can use any pcmcia devices: card flashes or network adaptars. Does it look like: kernel ---------------------------- hd64461 ---------------------------- pcmcia --------------------------- Flash | network | ... I would be grateful for any tips and explanations of these problems (what hardware aspects are exceptionally important? ) Pawel |
|
From: Studencki P. <Paw...@er...> - 2001-02-19 14:37:20
|
Hello, I've compiled new toolchain binutils and gcc. Now I'm trying to compile glibc-2.1.3 with a patch glibc-2.1.3-000515.diff and following configuration (it's worked with older gcc) : ------------------------------------------------------------------------ CC="sh-linux-gnu-gcc -ml -m3" \ RANLIB="sh-linux-gnu-ranlib" \ AS="sh-linux-gnu-gcc -ml -m3" \ LD="sh-linux-gnu-gcc -ml -m3" \ AR="sh-linux-gnu-ar" \ BUILD=gcc \ ../glibc-2.1.3/configure --target=sh-linux-gnu --enable-add-ons=crypt,linuxthreads \ --prefix=/usr/local/sh --disable-debug --disable-profile \ --host=sh3-linux --build=i686-linux \ --with-headers=/home/pawel/SH3/BUILD/linux/KERNEL-2.4.0/ebx_linux/include ------------------------------------------------------------------------ and I'm getting this error: --------------------------------------------------------------------------- sh-linux-gnu-gcc -ml -m3 -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings -m3 -ml -I../include -I. -I/home/pawel/SH3/BUILD/glibc/sh-linux-glibc3/c su -I.. -I../libio -I/home/pawel/SH3/BUILD/glibc/sh-linux-glibc3 -I../sysdeps /sh/sh3/elf -I../crypt/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../lin uxthreads/sysdeps/unix -I../linuxthreads/sysdeps/sh -I../sysdeps/unix/sysv/lin ux/sh/sh3 -I../sysdeps/unix/sysv/linux/sh -I../sysdeps/unix/sysv/linux -I../sy sdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/in et -I../sysdeps/unix/sysv -I../sysdeps/unix/sh -I../sysdeps/unix -I../sysdeps/ posix -I../sysdeps/sh/sh3 -I../sysdeps/sh -I../sysdeps/wordsize-32 -I../sysdep s/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic/elf -I../sysdeps/gene ric -nostdinc -isystem /usr/local/sh/lib/gcc-lib/sh-linux-gnu/2.97/include -i system /home/pawel/SH3/BUILD/linux/KERNEL-2.4.0/ebx_linux/include -D_LIBC_REEN TRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -c /home/pawel/S H3/BUILD/glibc/sh-linux-glibc3/csu/Mcrt1.c -o /home/pawel/SH3/BUILD/glibc/sh-l inux-glibc3/csu/Mcrt1.o cc1: Internal error: Segmentation fault. Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make[2]: *** [/home/pawel/SH3/BUILD/glibc/sh-linux-glibc3/csu/Mcrt1.o] Error 1 make[2]: Leaving directory `/home/pawel/SH3/BUILD/glibc/glibc-2.1.3/csu' make[1]: *** [csu/subdir_lib] Error 2 make[1]: Leaving directory `/home/pawel/SH3/BUILD/glibc/glibc-2.1.3' make: *** [all] Error 2 capella:/home/pawel/SH3/BUILD/glibc/sh-linux-glibc3 # -------------------------------------------------------------------------- Has somebody any ideas what could it be? I suppose, I'm using inproper source files for a new toolchain, but I'm not sure and I don't know which sources are correct. Is it possible to use glibc-2.2.1 or 2.2.2 with other patches? What would you recommend? regards Pawel |
|
From: <fi...@gm...> - 2001-02-19 14:30:35
|
Hi! I hope you don't mind me asking some real newbie questions :)... We're currently working on an US7708EVB board, which doesn't even allow in-circuit flash programming... Which boards do you use? I've heard some things about Hitachi's Solution Engine board... Where can I get this one??? Thanx a lot, any input is very appreciated! finr -- Sent through GMX FreeMail - http://www.gmx.net |
|
From: Philipp R. <pr...@ma...> - 2001-02-19 13:31:14
|
On Sun, 18 Feb 2001, NIIBE Yutaka wrote:
> While implementing RTC routine in SH IPL+g:
> --------------------------
> static unsigned long get_tick_1 (void)
> {
> unsigned int cnt128, sec, min, hour;
>
> while (1)
> {
> p4_outb (RCR1, 0); /* Clear CF-bit */
>
> cnt128 = (p4_inb (R64CNT) ^ RTC_BIT_CHANGE);
> sec = p4_inb (RSECCNT);
> min = p4_inb (RMINCNT);
> hour = p4_inb (RHRCNT);
>
> if ((p4_inb (RCR1) & RCR1_CF) == 0)
> break;
> }
>
> BCD_TO_BIN(sec);
> BCD_TO_BIN(min);
> BCD_TO_BIN(hour);
>
> return cnt128 + 128*(sec+60*(min+60*hour));
> }
> --------------------------
>
> I think I've found a hardware bug(? or feature) of SH-4. I need to
> set RTC_BIT_CHANGE as 0x40, to get the straight value of the tick.
> Without this, the tick value goes backward(!) sometime.
This is bad. I don't have access to my SuperH machine to test right now,
but I would suggest we stop using the 128 Hz register until we found a
reliable way to detect the chip bug.
> If it's true, we need to fix our RTC related code. Could you please
> check your CPU? How about chips by ST?
I think my CPU clock calibration code should work fine if you just delete
the code reading R64CNT. I haven't checked the recent changes committed
to it though.
|
|
From: Stuart M. <Stu...@st...> - 2001-02-19 12:15:52
|
Niibe-san
Yes, I saw the same behaviour, both on the SH7750 and the ST40STB1.
In fact as part of the changes I checked in for the STB1 boards was
a 'fix' to rtc.c to handle this. At the moment it is unconditional, but
if it doesn't occur on SH3 parts, then it sounds like we need to make it
conditional as you suggest.
What's the difference between the SH7750 and SH7750S? That's a new one
on me!
Stuart
On Feb 18, 12:22pm, gn...@m1... wrote:
> Subject: [linuxsh-dev] SH-4 RTC
>
> While implementing RTC routine in SH IPL+g:
> --------------------------
> static unsigned long get_tick_1 (void)
> {
> unsigned int cnt128, sec, min, hour;
>
> while (1)
> {
> p4_outb (RCR1, 0); /* Clear CF-bit */
>
> cnt128 = (p4_inb (R64CNT) ^ RTC_BIT_CHANGE);
> sec = p4_inb (RSECCNT);
> min = p4_inb (RMINCNT);
> hour = p4_inb (RHRCNT);
>
> if ((p4_inb (RCR1) & RCR1_CF) == 0)
> break;
> }
>
> BCD_TO_BIN(sec);
> BCD_TO_BIN(min);
> BCD_TO_BIN(hour);
>
> return cnt128 + 128*(sec+60*(min+60*hour));
> }
> --------------------------
>
> I think I've found a hardware bug(? or feature) of SH-4. I need to
> set RTC_BIT_CHANGE as 0x40, to get the straight value of the tick.
> Without this, the tick value goes backward(!) sometime.
>
> I see no problem for SH7709A, so I set RTC_BIT_CHANGE as 0 on SH7709A.
>
> If it's true, we need to fix our RTC related code. Could you please
> check your CPU? How about chips by ST?
>
> I've checked my CqREEK SH-4 and SolutionEngine SH7750 and
> SolutionEngine SH7750S. Both of SH7750 and SH7750S has this issue.
> --
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>-- End of excerpt from gn...@m1...
|
|
From: Jaswinder S. <jas...@ya...> - 2001-02-19 04:13:26
|
Dear Nao, Thanks for your help, I see . The biggest negative point of running kernel from ROM is that ROM speed is slow :( Any how , thanks for your help, Best Regards, Jaswinder --- Naokado OGISO <og...@li...> wrote: > Hi Jaswinder, > > see http://linuxsh.sourceforge.net/faq/faq.html > at "2.7. How do I use a kernel directly from ROM? ". > > > Dear Mitch and others , > > > > Thanks for your reply. > > > > what changes i have to made in kernel so that i > can > > run kernel from Area 0 , means i keep my kernel in > ROM > > and i execute my kernel from ROM . > > > > Thanks , > > > > Best Regards , > > > > Jaswinder. > > --- > Nao > > > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ |
|
From: Naokado O. <og...@li...> - 2001-02-19 02:53:39
|
Hi Jaswinder, see http://linuxsh.sourceforge.net/faq/faq.html at "2.7. How do I use a kernel directly from ROM? ". > Dear Mitch and others , > > Thanks for your reply. > > what changes i have to made in kernel so that i can > run kernel from Area 0 , means i keep my kernel in ROM > and i execute my kernel from ROM . > > Thanks , > > Best Regards , > > Jaswinder. --- Nao |
|
From: Jaswinder S. <jas...@ya...> - 2001-02-19 02:33:43
|
Dear Mitch and others , Thanks for your reply. what changes i have to made in kernel so that i can run kernel from Area 0 , means i keep my kernel in ROM and i execute my kernel from ROM . Thanks , Best Regards , Jaswinder. --- Mitch Davis <md...@po...> wrote: > Jaswinder Singh wrote: > > > > > Mitch Davis wrote: > > > And you MUST use some form of bootloader - it's > not > > > possible to > > > jump directly to the kernel start after powerup. > > > > > > > Can you please explain me why it is *not* possible > to > > jump directly to the kernel start after powerup. > > When the SuperH first boots, the only memory area > which > it can access is area 0, which should contain ROM. > The areas > which contain RAM will not be available until the > BSC settings > are programmed. So a direct jump to the kernel > would fail > because there would be no available RAM. > > It's the job of the bootloader (no matter how small) > to > program the BSC. > > Regards, > > Mitch. > -- > mailto:mj...@al... > mailto:md...@po... __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ |
|
From: Mitch D. <md...@po...> - 2001-02-19 00:56:50
|
Jaswinder Singh wrote: > > > Mitch Davis wrote: > > And you MUST use some form of bootloader - it's not > > possible to > > jump directly to the kernel start after powerup. > > > > Can you please explain me why it is *not* possible to > jump directly to the kernel start after powerup. When the SuperH first boots, the only memory area which it can access is area 0, which should contain ROM. The areas which contain RAM will not be available until the BSC settings are programmed. So a direct jump to the kernel would fail because there would be no available RAM. It's the job of the bootloader (no matter how small) to program the BSC. Regards, Mitch. -- mailto:mj...@al... mailto:md...@po... |
|
From: NIIBE Y. <gn...@m1...> - 2001-02-18 03:21:39
|
While implementing RTC routine in SH IPL+g:
--------------------------
static unsigned long get_tick_1 (void)
{
unsigned int cnt128, sec, min, hour;
while (1)
{
p4_outb (RCR1, 0); /* Clear CF-bit */
cnt128 = (p4_inb (R64CNT) ^ RTC_BIT_CHANGE);
sec = p4_inb (RSECCNT);
min = p4_inb (RMINCNT);
hour = p4_inb (RHRCNT);
if ((p4_inb (RCR1) & RCR1_CF) == 0)
break;
}
BCD_TO_BIN(sec);
BCD_TO_BIN(min);
BCD_TO_BIN(hour);
return cnt128 + 128*(sec+60*(min+60*hour));
}
--------------------------
I think I've found a hardware bug(? or feature) of SH-4. I need to
set RTC_BIT_CHANGE as 0x40, to get the straight value of the tick.
Without this, the tick value goes backward(!) sometime.
I see no problem for SH7709A, so I set RTC_BIT_CHANGE as 0 on SH7709A.
If it's true, we need to fix our RTC related code. Could you please
check your CPU? How about chips by ST?
I've checked my CqREEK SH-4 and SolutionEngine SH7750 and
SolutionEngine SH7750S. Both of SH7750 and SH7750S has this issue.
--
|
|
From: Bryan R. <br...@ix...> - 2001-02-18 02:14:06
|
Hi, In order to get khttpd.o to load on SH4, strncat has to be exported in sh_ksyms.c. here's the patch: --- arch/sh/kernel/sh_ksyms-old.c Sat Feb 17 18:10:19 2001 +++ arch/sh/kernel/sh_ksyms.c Sat Feb 17 18:10:34 2001 @@ -47,6 +47,7 @@ EXPORT_SYMBOL(strlen); EXPORT_SYMBOL(strchr); EXPORT_SYMBOL(strcat); +EXPORT_SYMBOL(strncat); /* mem exports */ EXPORT_SYMBOL(memchr); I think this should probably go into the main tree. Comments? Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Jaswinder S. <jas...@ya...> - 2001-02-17 16:21:18
|
Dear Mitch and others , Dear Mitch , I am sorry for late reply. I am having some doubts . --- Mitch Davis <md...@po...> wrote: > Mitch Davis wrote: > And you MUST use some form of bootloader - it's not > possible to > jump directly to the kernel start after powerup. > Can you please explain me why it is *not* possible to jump directly to the kernel start after powerup. > Regardless of which bootloader is used, that > bootloader will > certainly need to set the BSC correctly before > jumping to the kernel > start. > Why dont kernel initialize BSC as per its requirements even though bootloader already initialized BSC . What is problem in double initialization of BSC ? Thanks for your help. Best Regards, Jaswinder. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ |
|
From: <yos...@hi...> - 2001-02-16 05:49:47
|
Here is the register map for MS7751SE01. / yoshii /* Address Name Initial-val [bit] Signal ... */ h'1b000000 ILCRA h'FEBA [15:12] ~SLOT_IRQ8 [11:8] ~SLOT_IRQ7 [7:4] ~SLOT_IRQ6 [3:0] ~SLOT_IRQ5 h'1b000002 ILCRB h'7642 [15:12] ~SLOT_IRQ4 [11:8] ~SLOT_IRQ3 [7:4] ~SLOT_IRQ2 [3:0] ~SLOT_IRQ1 h'1b000004 ILCRC h'0D91 [15:12] ~PC_SIRQ3 [11:8] ~PC_SIRQ2 [7:4] ~PC_SIRQ1 [3:0] ~PC_SIRQ0 h'1b000006 ILCRD h'0000 [15:12] PCI_INTA# [11:8] PCI_INTB# [7:4] PCI_INTC# [3:0] PCI_INTD# h'1b000008 ILCRE h'000C [15:12] Reserved [11:8] Reserved [7:4] NMI [3:0] INTR h'1b00000a ILCRF h'0000 [15:12] INIT [11:8] CPURST [7:4] ~IGNNE [3:0] ~A20M h'1b00000c ILCRG h'0000 [15:0] Reserved h'1b00000e ILCRH h'0000 [15:0] Reserved h'1b000010 IRQTST h'0000 [15:0] IRQ Level h'1b000012 Reserved h'0000 [15:0] Reserved h'1b000014 Reserved h'0000 [15:0] Reserved h'1b000016 Reserved h'0000 [15:0] Reserved h'1b000018 Reserved h'0000 [15:0] Reserved h'1b00001a Reserved h'0000 [15:0] Reserved h'1b00001c Reserved h'0000 [15:0] Reserved h'1b00001e IDR h'0001 [15:0] Board ID --- |
|
From: Ian da S. <ida...@mv...> - 2001-02-16 04:13:20
|
Hi all, Does anyone know how INT_A, INT_B, INT_C, and INT_D from the PCI controller on the SH7751 map to the externel interrupts (i.e. IRL3-0) on the Hitachi Solution Engine? The PCI interrupts get decoded by an FPGA, and I can't figure out the logic in the FPGA. Thanks, Ian. |
25 messages has been excluded from this view by a project administrator.
