Subject: linux-2.2.1-philb-990222

From: Philip Blundell <[email-masked]>
Date: Mon, 22 Feb 1999 18:31:10 +0000

I've put a new kernel patch on ftp.netwinder.org.  This includes:

 - actually do the "disable FIQs while updating irq masks" thing, since Econet
   doesn't stand much of a chance without.  If you're using floppies on an
   old Acorn machine, especially in high bandwidth modes, be careful.  
   RiscPCs and anything non Acorn won't be affected.

 - /proc/cpuinfo now includes a `machine serial number' field.  The only 
   machine where this currently does anything exciting is the A5000 which puts 
   its unique ID there.  This would probably work for the RiscPC too (just 
   needs enabling in setup.c); if anybody tries it, let me know what happens.
   NetWinders with a new enough NeTTrom might also get a valid number for 
   this.

 - usual other stuff, see the CHANGES.philb file (hopefully now more or less 
   up to date) for full details.

p.

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

---

From: Matthew Wilcox <[email-masked]>
Date: Mon, 22 Feb 1999 23:55:13 +0100

On Mon, Feb 22, 1999 at 06:31:10PM +0000, Philip Blundell wrote:
>    machine where this currently does anything exciting is the A5000 which
>    puts its unique ID there.  This would probably work for the RiscPC too
>    (just needs enabling in setup.c); if anybody tries it, let me know what
>    happens.  NetWinders with a new enough NeTTrom might also get a valid
>    number for this.

Oooh.  That's useful for people who have network slot cards.  Now we
just need to figure out what wacko way the EtherM is wired up..

-- 
Matthew Wilcox <[email-masked]>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 23 Feb 1999 13:18:31 +0000

>Oooh.  That's useful for people who have network slot cards. 

Good thinking.  That actually hadn't occurred to me. :-)

p.

---

From: "Christophe Leroy" <[email-masked]>
Date: Tue, 23 Feb 1999 15:44:34 +0100

I've patched my working rmk4 with your patches, now kernel panics 
telling: couldn't get rx irq for rs285

What's wrong ?

Christophe

---

From: Philip Blundell <[email-masked]>
Date: Tue, 23 Feb 1999 15:29:21 +0000

>Found myself:  drivers/char/in tty_io.c, you call twice rs285_init();

Doh, thanks.  I thought I'd fixed that but clearly not.

p.

---

From: christophe leroy <[email-masked]>
Date: Tue, 23 Feb 1999 16:23:04 +0000

#ifdef CONFIG_ESPSERIAL  /* init ESP before rs, so rs doesn't see the
port */
        espserial_init();
#endif
#ifdef CONFIG_SERIAL_21285
        rs285_init();
#endif
#ifdef CONFIG_SERIAL
        rs_init();
#endif
#ifdef CONFIG_SERIAL_21285
        rs285_init();
#endif
#ifdef CONFIG_MAC_SERIAL
        macserial_init();
#endif
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 24 Feb 1999 16:14:48 +0000

>But, as far as I remember, mmap is not synchronous. So
>if you write 0x40404040, then your word at the same location, it
>doesn't mean that it will be really written on the flash,
>so you can't program like that.

If you mmap() the flash, it literally means that the flash device will be 
mapped into your address space.  Since it's mapped uncached writes will go 
straight through.

>Why not doing a write function ? Even if there is one
>for NETWINDER, one for CATS and one for EBSA285 

The reason for not putting a flash write function in initially was that it 
depends too much on the particular flash chip.  Every device has a different 
programming algorithm.

For EBSA-285 and other machines with 32-bit flash you can just mmap 
/dev/flash and program it that way (though mmap'ing /dev/mem at the right 
offset would do just as well).  The problem is that if your flash is only 8 
or 16 bits wide you need to do additional messing with the Footbridge to get 
the data to turn up in the right place.

The way I was most recently planning to do it was to provide a primitive 
write() that just sends bytes to the flash doing the correct byte-manipulation 
stuff.  The device-dependent bits would still be in user space and it would be 
generic to EBSA-285 and (I think) CATS, though not NetWinder because that has 
extra hardware that needs to get involved.  I just haven't got around to 
implementing it yet.

p.

---

From: christophe leroy <[email-masked]>
Date: Wed, 24 Feb 1999 16:55:17 +0000

In your flash driver, you tell that there is no write fonction
and that we must mmap and play flash dependent tricks.

Christophe