Subject: Re: Debian ports for RiscPC, ARM710, etc.

From: Russell King <[email-masked]>
Date: Thu, 1 Oct 1998 08:54:02 +0100 (BST)

Nicolas Pitre said:
> This kind of message makes me mad when I see it.  You should be aware that
> there isn't only English in the world even if Americans were part of the
> first computer designs and didn't bother about other characters than the
> plain dumb ASCII.  SMTP and NNTP are 8 bits now and since I actually can
> see those quotes right even from the above wich is a reply from your
> mailer I must conclude that your mailer and the SMTP gateways on the path
> from it to the mailing list handle high ASCII just fine.  These characters
> are displayed correctly within Winblows and Linux too, even in text mode
> which is what I use.

Well, I read all my mail in both X and text mode under Linux with elm (+mime
extensions) and it doesn't come out correctly on that.

--
Russell King ([email-masked])
Millbank Electronics Tel: 01825 764811 Fax: 01825 761620

---

From: Russell King <[email-masked]>
Date: Thu, 1 Oct 1998 08:57:01 +0100 (BST)

Elijah L. Wright said:
> you know, i personally don't have time to deal with this kind of crap.
> 
> if the mailer or the editor you're using simply can't deal with the kind
> of characters that are being used, perhaps you need to get a new piece of
> software.  pine/linux in latin-1 mode handles all of what's been posted
> just jolly.
> 
> if you're going to have a charset-snob flamewar, at least stop cc'ing
> lists.  UTF-8 is fine.  so are a lot of other charsets.  don't be a bigot.
> 
> i bet people are unsubscribing because of things like this.  don't waste
> everyone's time with your petty argument.

And as you say, you don't have time for this, and nor do I.  So either
stop waring publically, or you will be unsubscribed.  As you say, stop
CC:'ing my list.

---

From: James Craig <[email-masked]>
Date: Fri, 2 Oct 1998 18:47:16 +0100 (BST)

On Tue, 29 Sep 1998, David Alan Gilbert wrote:

> James Craig wrote:
> > <fishes out his Psion 5>
> > <goes to machine hardware page>
> > Processor: ARM7100
> > Speed: 18.432MHz.
> > ROM: 6M
> > RAM: 8M
> > So there you go. I think it's pretty similar to the ARM7500 but designed
> > for a palmtop instead of a normal PC.
> 
> I think there are some people who've looked at porting to Psion; but I haven't
> heard anything from them lately.
I'm on the lists for the people at RedHat who're trying to do this;
Unfortunately, they're too busy working on getting a bootloader running to
even be thinking abuot the kernel. I gather there aren't any great
problems there though - the problems are mostly to do with things like
storage space.

--
James Craig <[email-masked]>
            <[email-masked]>

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: James Craig <[email-masked]>
Date: Fri, 2 Oct 1998 18:59:56 +0100 (BST)

On Wed, 30 Sep 1998, Eduard Pfarr wrote:

> »Phil Norman« schrieb in Artikel
> <[email-masked]> folgendes:
> 
> > > If I did understand Jim and the others right they intend to do an ARMv3
> > > release which will work on any ARM »below« StrongARM - ie RiscPCs with
> >                                      ^     ^
> > Please stop using the above highlighted characters; they're high ASCII,
> > and really should not be used in emails.
> 
> Unusual - 3/4 of the European countries need »high ASCII« chars in their
> mother language and people from there use these characters in e-mails as
> well as Usenet articles. I've done this successfully for many years now,
> too, and it works fine on Windoze and RISC OS. If it's a problem here I
> will have to do something about it.
Truthfully, it's just irritating, because they're not the normal english
quote characters. It needs a concious mental effort to figure out what on
earth they're meant to *be*. :)
You should avoid using high-bit characters though, because they're *not*
guaranteed to look the same on everyone's terminals. On mine they look
like >> and << respectively for the two you're using, but that's not
always the case.
> 
> 
> ARM6xx and ARM7xx (and slower than must be on StrongARM RiscPCs). 
> > 
> > No, you did not understand correctly.  Any linux-arm stuff compiled for v3
> > ARMs will work on the StrongARM.
> 
> Great to hear.
> 
> However does »slower than must be on StrongARM RiscPCs« apply?
That's what everyone is arguing about. It shouldn't make a gigantic
difference, IMHO, but I'm no guru on these matters. :)
--
James Craig <[email-masked]>
            <[email-masked]>

---

From: James Craig <[email-masked]>
Date: Fri, 2 Oct 1998 19:02:32 +0100 (BST)

On Tue, 29 Sep 1998, Russell King - ARM Linux Admin wrote:

> BTW, DMA doesn't seem to work with this drive (Conner CFS1081A) - does anyone
> know if this drive is DMA capable?  According to hdparm -i:
> 
>  RawCHS=2097/16/63, TrkSize=0, SectSize=0, ECCbytes=4
>  BuffType=0(?), BuffSize=0KB, MaxMultSect=16, MultSect=off
>  DblWordIO=no, maxPIO=1(medium), DMA=yes, maxDMA=2(fast)
>  CurCHS=2097/16/63, CurSects=2114180, LBA=yes, LBAsects=2114180
>  tDMA={min:120,rec:120}, DMA modes: *mword0 mword1 mword2
>  IORDY=on/off, tPIO={min:383,w/IORDY:120}, PIO modes: mode3 mode4
> 
> Anyone know what this means?  i'm guessing that it means that DMA mode 'mword0'
> is supported, but none of the other modes.
Compare with my nice posh drive which supports any DMA mode you throw at
it; I'm not honestly sure, but I think the * indicates the highest mode it
supports rather than meaning "that mode is supported"

 Model=Maxtor 90680D4, FwRev=PAS23B15, SerialNo=V405JQEA
 Config={ Fixed }
 RawCHS=13176/16/63, TrkSize=0, SectSize=0, ECCbytes=29
 BuffType=3(DualPortCache), BuffSize=256kB, MaxMultSect=16, MultSect=16
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
 CurCHS=13176/16/63, CurSects=13281408, LBA=yes, LBAsects=13281408
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4

---

From: Alan Cox <[email-masked]>
Date: Sun, 4 Oct 1998 15:05:13 +0100 (BST)

> (holdups on the Psion5 port: mainly, the chips they use are organised in
> such a way that you only get 512k contiguous with MMU off. Kernel wasn't
> happy running in that sort of space when last tried :-(

So keep the MMU on 8)

head.S can create a virtually mapped kernel and thats been done for other
platforms.