Subject: Re: linux-2.2.1-philb-990210

From: Russell King <[email-masked]>
Date: Thu, 11 Feb 1999 21:58:44 +0000 (GMT)

Philip Blundell said:
> This patch is now on ftp.netwinder.org.  It should fix a few problems that 
> people had with the previous patch.  Fingers crossed, NWFPE-as-module really 
> should work this time and I added the LEDs bits that got missed before
> around - basically you can now ask them to turn a particular colour.  BTW, 
> it would be nice if someone with an EBSA-285 could try this and see whether 
> the LEDs seem to do the right thing.

Would you mind discussing/forwarding your changes and bug fixes to the relevent
maintainers at some point, rather than just overruling them snatching the maintainence
from them?  I find this extremely discourtious. (and you wonder why I jump down your
throat from time to time).

> The floppy-DMA thing that I posted here the other day is now included.  If it 
> eats your disks I'd like to hear about it.  And, uh, that's about it.

Have you tested it in the highest resolution?  Although I haven't checked yet,
from the calculations I did on Thursday night, there is only about 1us every 20us
(20us is about the period between each floppy FIQ) *worst case* to allow the
foreground task to run (incuding the execution of the actual FIQ routine.

A single floppy FIQ cycle occurs about every 20us, and *MUST* be loaded within
this time or else floppy corruption occurs.  What I'm not sure of is the latency
that can be allowed between the floppy requesting data and the data actually being
presented.  I would imagine that this is more stringent than 20us.

Given that a single floppy FIQ cycle occurs every 20us,

 - each video transfer consists of a 4 word DMA.  At the highest video resolution
   this occurs every 1.778us, and lasts 1.2us.  In a single FIQ cycle, the video
   transfer occurs 11.25 times, which gives a total bus usage of 13.5us.

 - the cursor DMA consists of a 4 word DMA.  This occurs every 31us.  Hence it will
   more than likely occur once every FIQ cycle and lasts 1.2us.

 - sound DMA consists of a 4 word DMA, which at 20kHz occurs every 50us.  It will
   take around 1.2us.

 - a podule access takes 1.2us for one cycle.  A 4 register LDM or STM would take
   around 3us.

 - this takes out about 18.9us worst case every 20us and does not include the
   time the ARM takes to synchronise with the FIQ request, enter the FIQ routine,
   process the FIQ and return from it.

Hence I still don't believe that shaving an extra couple of cycles off the FIQ
will give enough time to disable and enable FIQs, which is your main reason for
implementing this change.

NOTE that if the video FIFO settings in VIDC are not programmed correctly, even
with the FIQ code as is, you *will* get undetectable corruption of floppies when
you write to them (the disk controller does not appear to flag underruns as an
error).

--
Russell King ([email-masked])
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 12 Feb 1999 10:01:51 +0000

Russell King wrote:

>Would you mind discussing/forwarding your changes and bug fixes to the 
>relevent maintainers at some point, rather than just overruling them 
>snatching the maintainence from them?  I find this extremely discourtious.

Once I'm happy that the changes are correct, yes.  The only way for me to find 
this out is to ask other people to try them.  As you are so fond of pointing 
out, your "official" kernel is supposed to be stable so it probably isn't 
the best place to test experimental changes.  In fact if you consult the 
guidelines in the MAINTAINERS file, they explicitly suggest making patches 
available for testing before bothering the maintainer.

As always, if you'd like to discuss the patches then I'd be glad to hear 
your comments.

>(and you wonder why I jump down your throat from time to time).

Frankly I've long ago given up wondering about things like that.

>Have you tested it in the highest resolution?

No.  If necessary I'd be happy to do what RISC OS appears to and turn off 
video DMA in such modes during floppy access.  (And since in the 
highest-bandwidth modes the video DMA consumes over half the available bus 
bandwidth it will be pretty hard to get any work done in such a mode anyway.)

>will give enough time to disable and enable FIQs, which is your main reason 
>for implementing this change.

It was the main motivation for making the change in the first place, yes.  
Regardless of whether it actually achieves this objective or not do you see 
any reason not to install it?

Incidentally, remember that the ARM3 is of course cached and so it isn't 
impacted as badly by bus latencies as naive calculations might show.  And, 
although there is indeed all this DMA going on in the background it happens in 
many small chunks (after any of which the ARM can potentially get on the bus), 
not in one large uninterruptible lump.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 12 Feb 1999 15:25:33 +0000 (GMT)

> available for testing before bothering the maintainer.

I'm sorry - I can't find this in the Maintainers file.  Could you please
give me a line number?

> bandwidth it will be pretty hard to get any work done in such a mode anyway.)

Oh well, maybe we ought to ensure that nothing above 320x256 works for anyone.
Then we'll have lots of bandwidth to play with.

I don't think that mode 31 (which is what those figures were determined from)
is that bad.

> not in one large uninterruptible lump.

Cache or no cache, the floppy DMA still has to move data, which will require
the bus.  I don't think that the cache will have much effect on the timings.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 12 Feb 1999 15:58:41 +0000 (GMT)

With the FDC in high-density (500kbps) mode, the peak interval between
requests for data is actually 16us, not 20us, as measured on the A5000.
Also, the 18.9us should be altered for the 36MHz MEMC clock instead of
the 24MHz MEMC clock, which is an estimated 12us.  (this is an over
simplification, since it takes no account of the VIDC transfer rate
for a built in mode definition).

However, as I have pointed out, the time for the ARM to load the required
byte when writing is more critical than this - it will not work if it
requests a byte and you load it 15.9us after.  That is what the old
residual checking that I had in my floppy driver was supposed to catch.

NOTE:  If you do exceed the required timing when writing, you will not
know about it until you try to read it.  Don't forget that Linux caches
the disk contents, so simply writing and then reading won't tell you
if it's written properly.  You need to close /dev/fd and eject the
disk between read and write (or call the BLKFLSBUF ioctl).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 12 Feb 1999 16:31:30 +0000

>I'm sorry - I can't find this in the Maintainers file.  Could you please

About lines 7 to 40.  Firstly one is exhorted to "release a few alpha test 
versions to the net", then to make the patch "generally available for 
testing", and only after that to send it to the maintainer in a form ready for 
merging.

>> bandwidth it will be pretty hard to get any work done in such a mode anyway.
>

If you want to continue this discussion in a constructive manner, fine.  If 
you don't want to continue it at all, that's also fine.  This sort of comment 
just wastes everybody's time.

>the bus.  I don't think that the cache will have much effect on the timings.

Why don't you analyse the actual code sequences, figure out whether the 
latency *would* in fact be too long, and then report back your findings?  I 
don't see much benefit in speculation.

If the answer is that disabling FIQs while updating the IRQ mask is 
unacceptable, do you have any alternative suggestions for solving the actual 
problem at hand (ie preventing contention on the IRQ mask registers betweeen 
two threads)?

p.

---

From: Mark Koek <[email-masked]>
Date: Mon, 15 Feb 1999 14:01:09 +0100

Philip Blundell wrote:

> If necessary I'd be happy to do what RISC OS appears to and turn off
> video DMA in such modes during floppy access.

<NOSTALGIA>
Yes! I used to get that flashing screen during floppy access on the
ancient Acorns (pre-1990, the ARM2 ones with the slow MEMC).
</NOSTALGIA>

On a more serious note: lurking on this list for a few months taught me
(among many other things) that two important contributors to ARM Linux
like to take a swipe at each other from time to time.

Please don't let this escalate. That wouldn't do Linux in general, or
anyone in particular, any good.

'bye,

Mark Koek

---

From: Tim Lindquist <[email-masked]>
Date: Tue, 16 Feb 1999 17:33:12 +1100

I'm having problems building a cross compiler on solaris.
When running  make, I get:

checking whether the C compiler (arm-linux-gcc -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler
cannot create executables.
gmake: *** [configure-target-libiberty] Error 1

Before I got to this stage, I had the egcs-1.1.1 source,
and got 3 patch files for it that I applied consecutively:

egcs-1.1.1-prerelease-2-arm-diff-981117.gz
egcs-1.1.1-prerelease-2-arm-diff-981117-981124
egcs-1.1.1-prerelease-2-arm-diff-981124-981125

I got the following message during the final patch:

patching file `gcc/f/intdoc.texi'
Reversed (or previously applied) patch detected!  Assume -R? [y]

I created an egcs-1.1.1-build dir, and from there ran:

 ../egcs-1.1.1/configure --target=arm-linux
--prefix=/home/elph/tjl/work/sw/armlinux/

and then ran make.

What am I doing wrong?

---

From: Philip Blundell <[email-masked]>
Date: Tue, 16 Feb 1999 09:50:04 +0000

>egcs-1.1.1-prerelease-2-arm-diff-981124-981125

Try getting the latest patch from ftp.netwinder.org:/users/p/philb.  I think 
it's dated 990113 or thereabouts.  (I don't think this is your problem; just 
as a matter of general principle it's best to use the latest sources.)

>What am I doing wrong?

Probably nothing, in fact.  The cross-compiler has been built and is now being 
used to try to cross-compile the target libraries.  This fails because you 
haven't yet installed the target runtime system (ie glibc).

There are some notes about this sort of thing on my web site 
(http://www.tazenda.demon.co.uk/phil/armlinux) and I think they mention this 
and what you can do about it.

p.

---

From: Tim Lindquist <[email-masked]>
Date: Fri, 19 Feb 1999 16:56:17 +1100

I looked at this web page. It talks about::

If you are trying to bootstrap a development environment for the first time on
this system you will find that not everything will build first time around.  The
only things that matter at this stage are those that are
built if you type `make LANGUAGES="c"' in the `gcc' subdirectory.  In order to
get libgcc2 to compile you may need to add -Dinhibit_libc to the CFLAGS that are
used.  The easiest way to do this is to
fiddle the Makefile by hand.  Once enough of the compiler is built you can
install it - again you may need to be in the gcc subdirectory and use
LANGUAGES="c" to get this to complete without errors.
<<<<

I have nothing in the gcc directory but
confdefs.h  config.log

I think the test is either failing because arm-linux-gcc doesn't point
to anything, or because it's compiling an arm binary on solaris and
then cant test it on solaris.

Anyway, I'm getting pretty lost, can anyone tell me what is missing?

---

From: [email-masked]
Date: Fri, 19 Feb 1999 09:38:17 +0100

> I have nothing in the gcc directory but

did you run configure ? configure creates makefiles

> Anyway, I'm getting pretty lost, can anyone tell me what is missing?

I'm getting lost by reading this mail.
Let me sum up stages and tell me where it fails, I'll help you

- Compile and install binutils-1.9.1.0.19a
	./configure --target=arm-linux --prefix=where_you_want
	make
	make install
- add where_you_want/bin in your PATH
- Untar egcs, patch it, find . -name "*.rej"
- enter egcs dir, then ./configure --target=arm-linux --
prefix=wher_you_want_the_same
- modify makefile to add -Dinhibit-libc in CFLAGS
- make -i LANGUAGES=c
- make -i LANGUAGES=c install

compile glibc, with 
prefix=/where_you_want_not_the_same_as_above
make, make install

go back in egcs,
./configure --prefix=same_place_as_first_time --with-
headers=/where_you_put_glibc/include --with-
libs=/where_you_put_glibc/lib --target=arm-linux
make LANGUAGES="c c++" 
make LANGUAGES="c c++" install

DONE

Christophe

---

From: Nicholas Clark <[email-masked]>
Date: Fri, 19 Feb 1999 10:31:14 +0000 (GMT)

In the last mail [email-masked] said:
> From [email-masked]  Fri Feb 19 08:44:49 1999
> From: [email-masked]

> 	./configure --target=arm-linux --prefix=where_you_want

surely
make cross
if he's trying to make a cross compiler?

> > > --prefix=/home/elph/tjl/work/sw/armlinux/

should one configure with --host --target and --build when making a cross compiler?

Nick (guessing)

---

From: [email-masked]
Date: Fri, 19 Feb 1999 11:48:11 +0100

> if he's trying to make a cross compiler?

It works with just make, as you've allready told to configure that 
you want it beeing compiled for arm-linux and it sees that you are 
under sparc-linux or sparc-solaris, so it knows it will build a cross 
compiler. It works like that, at least on i486-linux

> should one configure with --host --target and --build when making a cross compiler?

Once again, normaly, as far as I remember what I did, --target is 
enough

Christophe

---

From: Melanie Rhianna Lewis <[email-masked]>
Date: Fri, 19 Feb 1999 12:30:56 +0000

Hi everyone,

With all the comments being I made I thought I'd give it a go so I've
downloaded binutils-2.9.1.0.19a at work and tried building it.  It works
for --target=arm-linuxaout (although the install falls over at the man
pages) but not for --target=arm-linux.  (Just use make once configured).

Its failing in elf32-arm.c which seems to be peppered with C++ comments
that my compiler doesn't like.  Are they supposed to be there if so, can
I just delete the relevant lines.  Its just that it seems to be the sort
of thing I would do when I was testing something.  Have I got a duff
copy of the binutils archive.

Melanie

-- 
+-------------------------------+----------------------------+
| Melanie Rhianna Lewis BSc MSc |  Gravitational Waves Lab   |
|   Java Programmer - TRIANA    | Physics and Astronomy UWCC |
+-------------------------------+----------------------------+
|             Email: [email-masked]            |
|             WWW: http://www.defaid.demon.co.uk/            |
+------------------------------------------------------------+
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 12:39:27 +0000

>that my compiler doesn't like.  Are they supposed to be there if so, can

Eww.  Just delete the offending comments.  They were put in during development 
and probably should have been removed long ago.

p.

---

From: Dave Baukus <[email-masked]>
Date: Fri, 19 Feb 1999 09:08:20 -0600

I can not seem to find the floating point emulator module mentioned under
Documentation/arm/nwfpe nor can I find the emulator by R. King alluded to in
the same docs.

Can somebody point me to the source for one of these ?
It might help me eliminate the SIGILLs being sent to almost every user process.

(two of the offending instructions are rfs and wfs - there is likely many more)

--
Dave Baukus
	Inet Technologies Inc. - R & D
	[email-masked]
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 15:24:29 +0000

>> if he's trying to make a cross compiler?

"make cross" is only needed for GCC.  For binutils you just do "make".

>> should one configure with --host --target and --build when making a cross 

There's no need.  You have to give --target but the host can be guessed and 
the build defaults to the host.

p.

---

From: Melanie Rhianna Lewis <[email-masked]>
Date: Fri, 19 Feb 1999 16:00:28 +0000

> and probably should have been removed long ago.

For those who want to know.  Having removed the comments and 'chmod 755
install-sh' it seems to have compiled fine on Solaris2.6.  Now for
egcs-1.1.1

Melanie

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 16:21:47 +0000

>Documentation/arm/nwfpe nor can I find the emulator by R. King alluded to in

NWFPE is in arch/arm/nwfpe.  The Acron emulator is not open source.

p.

---

From: Dave Baukus <[email-masked]>
Date: Fri, 19 Feb 1999 10:59:37 -0600

> NWFPE is in arch/arm/nwfpe.  The Acron emulator is not open source.

OK, I'm an idiot - but, I get the kernel from kernel.org and I get the 
Arm patches from netwinder and I have nothing under the arch/arm/nwfpe path.

---

From: Philip Blundell <[email-masked]>
Date: Fri, 19 Feb 1999 17:05:17 +0000

>Arm patches from netwinder and I have nothing under the arch/arm/nwfpe path.

Sounds like either you have the wrong version of the ARM patches or they 
didn't apply properly for some reason.  Here's what you should have:

fountain:~/new-linux-arm/2.2.1/linux$ ls arch/arm/nwfpe/
ARM-gcc.h             fpa11.h               fpopcode.h
ChangeLog             fpa11.inl             fpsr.h
Makefile              fpa11_cpdo.c          milieu.h
config.h              fpa11_cpdt.c          single_cpdo.c
double_cpdo.c         fpa11_cprt.c          softfloat-macros
entry.S               fpmodule.c            softfloat-specialize
entry26.S             fpmodule.h            softfloat.c
extended_cpdo.c       fpmodule.inl          softfloat.h
fpa11.c               fpopcode.c
fountain:~/new-linux-arm/2.2.1/linux$ 

p.