Subject: Re: Help required

From: "David A Brooks" <[email-masked]>
Date: Tue, 13 Oct 1998 09:23:14 +0100

This is a brief explanation as to screen resolutions in arm linux.

>From other postings and my experience there is no easy way to configure arm
linux once it's started.
But, it will stay in whatever mode you start it into.
(Note: Currently 16 & 24 bit colour are NOT supported and just create adot
pattern around the screen.)

You can:

1 - Change to required resolution in RiscOS, then start ArmLinux, which will
use whatever resolution you supplied.

2 - Add the Line "WimpMode [Screen Definition]" into the !Run file inside
!Linux

3 - Write a utility to allow you to change screen resolution, by programming
the VIDC, then tell the Kernel that the screen setup has changed and hope it
can handle it (Possible but not easy)

My personal choice is 1 for ease, or 2 if you use different resolutions in
RiscOS and ArmLinux.
Hope this helps, if not ignore all of the above.

Cheers,
    Dave

PS. If anything above is WRONG please correct it as I wouldn't like to be
giving incorrect information.

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

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 13 Oct 1998 20:08:00 +0100 (BST)

> Hope this helps, if not ignore all of the above.

Ok, I'll correct ;)

ARM Linux can (read should) cope with any 1-bpp, 4-bpp or 8-bpp RISC OS mode.
Since Linux does not touch the VIDC's registers (other than the palette),
Linux runs in whatever screen resolution RISC OS was last using.

Currently, !Linux runs a basic program - SetModeNew or SetModeOld, dependent
on whether you have RISC OS 3.5 or above.  These basic programs should be
edited to set what resolution you require.

This sounds like a good candidate for the FAQ, so expect it to appear shortly.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: dooby <[email-masked]>
Date: Wed, 14 Oct 1998 13:43:58 +0100 (BST)

Hi all,

I know there's been a lot of messages on this before, but I wish to know
whether anyone ever got a conclusive HowTo of doing this. My primary
reason for wanting it is to get Arm Linux onto my A4 - which assumes that
it's hardware is the same as the A5000 (I beleive it is).

Can anyone help with any info on the feasibility of this?

Cheers,

dooby

---

From: dooby <[email-masked]>
Date: Wed, 14 Oct 1998 13:52:06 +0100 (BST)

Hello,

I am running Arm Linux on my 8MB A5000, with my own compiled kernel of
2.0.33. I have tried setting the mode (in SetModeOld) to 28 or 15 but if I
try to 'startx' from Linux then the screen makes a slight sound (as though
powering down or changing mode) and the display goes black. I don't even
get a hint of seeing X start up, however it _does_ start up - I have to
kill it by typing reboot into an Xterm window I have set up.

The most worrying thing is, I *can* get X running in 16 colours (modes 12
or 27 or 31). The problem with this is that I get loads of errors about 
"can't allocate colour such_and_such", and nothing is very usable in
just 16 colours - it's hard enough getting the display visible (black
text on black backround is hard). Why doesn't 256 colours work?! I think
it must be due to my older hardware - is anyone running earlier kernels
successfully with 256 colour X on an A5000?

I do have a colourcard in the machine, but since I am using standard
modes, these just get passed through it - besides, I'm sure I've tried
removing the card before to check if it was that.

ISTR getting X in 256 colours in a release of 2.0.30/1 in mode 15 - anyone
else know of this problem (or fix)?#

Thanks for any help,

dooby

---

From: Philip Blundell <[email-masked]>
Date: Thu, 15 Oct 1998 09:41:19 +0200

>Can anyone help with any info on the feasibility of this?

What I did in the end was to fudge the kernel so that it called swapon() 
before starting init.  If you arranged for this to be driven by a command-line 
option you might even stand a chance of getting it past Linus. :-)

Incidentally, does anybody know how much setup stuff there is that needs doing 
to make an Archimedes/A5000 run that the kernel relies on RISC OS having done 
beforehand?  Obviously the initial video setup but nothing else leaps to mind.
I'm planning to have another go at putting a kernel in ROM on the A5000 to 
free up more memory. :-)

p.

---

From: Paul Vigay <[email-masked]>
Date: Thu, 15 Oct 1998 12:08:30 +0100

In article <[email-masked]>,

> Can anyone help with any info on the feasibility of this?

I'm not sure what the absolute minimum memory requirement for ArmLinux is.
Normal Linux should run in 4MB (although 8 is recommended) and as you say the
A4 is pretty much the same as an A5000 technically. However you will probably
need a bigger hard drive than the default A4 one as Linux would need rather
more than 60MB (or whatever the standard size is/was on A4's) as a partition.
Chris Pringle has a guide on installing ArmLinux on A5000 machines at
http://www.latrigg.demon.co.uk/Chris/Linux/linux.html which you might find
handy.
My own 'dummies guide' is at http://www.matrix.clara.net/Acorn/linux.html

-- 
Paul Vigay                                           Acorn Programming,
                                    __\\|//__	    Internet Consultancy
http://www.matrix.clara.net         (` o-o ')           & Web Design
-----------------------------------ooO-(_)-Ooo---------------------------

51 Things to do in a lift: 9. Offer name tags to everyone getting on the lift.  Wear yours upside-down.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Andrew Tuson <[email-masked]>
Date: Thu, 15 Oct 1998 19:07:11 +0100

In message <[email-masked]>

> Linux runs in whatever screen resolution RISC OS was last using.

Are you sure?  I normally run in 1024x768 with 32k colours, and Linux insisted
in starting up in 1280x1024 with 256 colours.

> edited to set what resolution you require.

Found that thanks.

-- 
Andrew Tuson

---

From: Philip Blundell <[email-masked]>
Date: Fri, 16 Oct 1998 10:33:24 +0200

>I think the memory setup could be useful.

Mmm.  I guess MEMC needs to be told its page size and that kind of thing.  
Ugh.

p.

---

From: Stefan Hanske <[email-masked]>
Date: Fri, 16 Oct 1998 11:27:00 +0200 (METDST)

> option you might even stand a chance of getting it past Linus. :-)

I've done it already, but I needed another Linux box to modify the root
disk (a mix of root/supplemental disk with shared libs on it) and as soon
as possible mkswap & swapon. Btw, there was a problem with one of the
mkswap's. It was complaining it couldn't determine the page size.

> I'm planning to have another go at putting a kernel in ROM on the A5000 to 

You need to call the kernel with R0 and R1 containing cartain values, and
I think the memory setup could be useful.

----------------------------------------------------------
|mailto: Stefan Hanske ([email-masked] |
|WWW : http://www.rzuser.uni-heidelberg.de/~shanske      |
|phone: I'm not silly                                    |
|--------------------------------------------------------|
| And don't forget to remember what you remembered not   |
| to forget to remember...				 |
----------------------------------------------------------

---

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

> in starting up in 1280x1024 with 256 colours.
Because Linux doesn't do 16bpp, presumably - it's maybe the closest 8bpp
mode? 
> > edited to set what resolution you require.
Don't remember what ATM, Russ, but there's some problem with one or other
of those - or there used to be, anyway. I'll wire up my A410/1 again
tonight see if I can't remember what.

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