Subject: User-not-very-friendly-at-all

From: "Frank T." <[email-masked]>
Date: Thu, 2 Jul 1998 15:59:13 -0700 (MST)

Greetings fellow armlinux users.

As this subject suggests, I think people are having trouble installing armlinux, as it seems that Russell, Philip, Matthew etc. see the situation only from the point of view of the highly experienced user.  One thing that I think is holding back the development of Armlinux is the fact that it is so damned hard to install.  This in turn limits the userbase and so feedback and development are then slowed.

And let's face it.  Installation is currently really hard, especially if you're hardware isn't completely standard, ie a different IDE disc controller card being used on its own - no acorn ide GASP!

How about Russell, you delegate :

* Ask someone (who knows what they are on about, like Philip or Matthew) to get going on some serious, well-structured documentation about the installation and use of Armlinux, which is currently lacking in comparison to every other linux/BSD port I've used.

* Make the introduction of a vaguely half feasible install method one of the highest priorities on the list, and if you're not interested in this then at least let someone who is contribute.  I've not met a hard to install linux system on any of the platforms I've used it on, until I met this.

* Release the source code to all the RiscOS tools, Partman, Linux, Writedisc, LinConfig etc.  Then people can compile their own versions, with their own hacks to get their (and other peoples) systems working.

I'm not moaning, just saying that there are people out there like me who use unix a lot and have done for a while without necessarily knowing the first thing about how it works, nor wanting to either.  It just strikes me that this project differs very much from RiscBSD : I have always found RiscBSD very easy to install.  If I have found it easy then no doubt others have too, and perhaps this is why it has progressed so well.  Software doesn't progress unless it gets used!

be nice,

frank t.  www.endtroducing.com

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

---

From: micm <[email-masked]>
Date: Fri, 03 Jul 1998 11:13:23 +0100

> Greetings fellow armlinux users.

Greetings earthling.

> As this subject suggests, I think people are having trouble installing armlinux, as it seems that Russell, Philip, Matthew etc. see the situation only from the point of view of the highly experienc…

I only had one problem with installing.  Didn't seem that hard.  And my setup
isn't exactly the most standard of setups....
 
> And let's face it.  Installation is currently really hard, especially if you're hardware isn't completely standard, ie a different IDE disc controller card being used on its own - no acorn ide GASP!

What's wrong with that?  Just partition it with partman, mount it from
installer, copy files then install....

> * Ask someone (who knows what they are on about, like Philip or Matthew) to get going on some serious, well-structured documentation about the installation and use of Armlinux, which is currently l…

Phil Norman has some good documents about installing ARMLinux.  Perhaps they
could be altered to include installing it from downloaded files and then put
on the ARMLinux web site.?

> * Make the introduction of a vaguely half feasible install method one of the highest priorities on the list, and if you're not interested in this then at least let someone who is contribute.  I've…

There is no easy way round this, except by writing an entirely new installer. 
The installer used is the standard Redhat installer, and as such expects to be
running on a pc.  If you follow Phil's instructions you can get round all the
problems with very little effort.
 
> * Release the source code to all the RiscOS tools, Partman, Linux, Writedisc, LinConfig etc.  Then people can compile their own versions, with their own hacks to get their (and other peoples) syste…

With the exception of perhaps Partman, I Don't think that this will help too much.

> I'm not moaning, just saying that there are people out there like me who use unix a lot and have done for a while without necessarily knowing the first thing about how it works, nor wanting to eith…

The best this I found was to go to the bookshop and buy one of the books that
comes with a linux CD and explains how to install and what to setup once the
system has been instaslled.  Reading this in conjuction with Phil's notes from
the web made it *very* easy to install.  As I said, the only problem I had was
that Partman wouldn't partition my disc.  This was because I had plugged it
into a Baildon IDE interface at one point and it had fiddles the partition
table.  Wiping the drive totally fixed this.

> be nice,

Tried to.  BTW, can you fix your mailer - it ain't formatting to 80
letters/line (mind you, as I'm writing this on a mac in Netscape, I wouldn't
be surprised if mine isn't either...).  Makes it *really* hard to read :-(

---

From: David Forbes <[email-masked]>
Date: Fri, 3 Jul 1998 12:23:53 +0100 (BST)

> > Greetings fellow armlinux users.

Greetings to anyone in neither category...    ;-)

I've no particular views on most of what's been said in this thread, but a

> on the ARMLinux web site.?

I think the problems that I have seen with documentation (like most large,
free, systems undergoing rapid development) is that after a while, there
are lingering copies of outdated versions (of, for example the
installation instructions) which tend to confuse people.  

> With the exception of perhaps Partman, I Don't think that this will help too much.

It would have helped me.  I had no RAM in my first bank (A7000+, you see),
and !Linux does like to load the kernel into your first bank, and will
complain otherwise.  Without the source code, there was nothing I could do
about it (other than install NetBSD, instead).  Whilst I recognise that
letting everyone have a free-for-all on the source code of these
utilities might be counter-productive, it does permit people to modify
things (and stand a chance of getting started) if they have not-standard
hardware.  

> the web made it *very* easy to install.  As I said, the only problem I had was

To be fair, I think it's easy to say that things are easy once you've done
them.  I found NetBSD tricky at first, but now that I've done it, it's
trivial.

Just my ha'penny's worth.

Have fun,
David.

PS - I'm well aware that sitting here and criticising is a lot easy than
doing...

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 3 Jul 1998 15:23:34 +0100 (BST)

> on the ARMLinux web site.?

I do have an admin-by-email system set up and ready to go here for the
site.  If anyone's interested, let me know and we can sort out the
details.

It's not too fancy yet, but it'll work for html pages.  GIF files
and such like will be slightly more painful until I've got the auto-
demime/uudecode stuff sorted.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 3 Jul 1998 15:04:13 +0100 (BST)

David Forbes writes:
> > > * Release the source code to all the RiscOS tools, Partman,
> > 
> > With the exception of perhaps Partman, I Don't think that thi
> 

Unfortunately though, !Linux is not the restriction.  Yes, !Linux does
load the kernel into the first RAM bank, but it's not a restriction of
!Linux itself.  !Linux is just ensuring that certain conditions which
absolutely have to be met are indeed met.

To allow Linux to take over the machine, the kernel must be loaded.  Then
the machine is cleanly shut down, and then the fun parts start happening.
The processors MMU is then turned off.  The kernel is then called which
self-decompresses.  The kernel is not position independent, and so has a
fixed address.  The fixed address is in the first RAM bank.

Hence, if you modified !Linux to load the kernel into the second RAM bank,
then you'd find that it doesn't work anyway.

I know, you picked a bad example!
   _____

---

From: David Forbes <[email-masked]>
Date: Fri, 3 Jul 1998 16:05:43 +0100 (BST)

> absolutely have to be met are indeed met.

I had a feeling this might be the case...

> then you'd find that it doesn't work anyway.

Even if there's no other RAM available?  I'll admit to not knowing the
gorey details of Linux kernel start-up, but surely it must be possible
(albeit with minor modification of the kernel if necessary).  I had been
assuming that physical RAM address zero would be the first available byte,
irrespective of bank number. (Okay, so I don't know the MMU to well
either...)

> I know, you picked a bad example!

To be fair, I picked an example which has directly affected me - I'm sure
there are others.

I don't mean to make too much of an issue of this as a) I'm running NetBSD
now and b) I've now fitted an extra SIMM which occupies bank 0.  The only
problem is that there was discussion a while back about getting it running
on an A7000(+) with a view to running on that portable.  I'm still
prepared to give it a bash (when I get myself a second machine at the
end of the summer), but I won't be able to fix this problem myself.

Have fun,

David.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 3 Jul 1998 17:37:39 +0100 (BST)

> irrespective of bank number. (Okay, so I don't know the MMU to well

Even if there's no other RAM available.  The problem comes from the fact
that the RiscPC's DRAM is not contiguous - it's split into banks.  In each
SIMM, there are two banks, giving you a total of 4 banks with each bank having
it's own base address.  Slot 0 Bank 0 is at physical address 0x10000000.
Slot 0 Bank 1 is at physical address 0x14000000.  Hence, if you don't
have RAM in slot 0, then you're got a hole from 0x10000000 to 0x18000000.

Now, the compressed kernel is built to be run at 0x10008000 with the MMU
turned off (this bit is fundamental), and as such, if you don't have any
RAM in the first RAM bank, the kernel cannot be executed at 0x10008000,
and therefore can't start.

You could build a kernel (after you've got it running - catch 22) to run
at 0x18008000, but then everyone who doesn't have slot 1 filled would fail.

There is one more restriction on the setting up of the kernel - the initial
page tables are located at a fixed address, also in the first RAM bank.

Since ALL RiscPCs are supplied from Acorn with the first RAM bank filled,
it amazes me why someone would leave it empty (you buy a 16MB SIMM to
upgrade your machine, so why not leave the original 8MB SIMM in there
so you get 24MB, because you're bound to need it in the future, OR
you remove the 8MB SIMM, so why not fill slot 0 first with the new SIMM)?

Am I being too logical?  Probably.
   _____

General protection fault while pouring water into bucket: hole in bottom.
Abort, Retry or Fail? ;) (Yes, I know, it gives the user too much info).
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: David Forbes <[email-masked]>
Date: Fri, 3 Jul 1998 19:34:58 +0100 (BST)

> Since ALL RiscPCs are supplied from Acorn with the first RAM bank filled,

But in this case, the problem arises with an A7000+.  I don't for one
minute suppose that there would be a problem of this nature with most RPCs
(otherwise it would have been discussed and fixed, no doubt).

> you remove the 8MB SIMM, so why not fill slot 0 first with the new SIMM)?

Neat, and logical and what most people would do.  However, if the base RAM
in an A7000+ is a SIMM, then this has slid by me and I apologise - having
had the lid off my machine several times it certainly doesn't appear to be
case.  However, when running !Linux with -debug it informs me that I have
4Mb in banks 3 and 4.  I have upgraded my machine, and now I have 16Mb in
the first bank (which corresponds to the vacant SIMM socket).  Which
solves the problem for me, but still leaves a gotcha for anyone else
following on.  (That's before we get to the various other problems.)  Now
we may have lost the point here - that is, IMHO, this is an example of a
case where having the source code available may have been beneficial. 

Ultimately, I think perhaps continuing this discussion any further would not
be beneficial.  The only other thing that I have to say is that perhaps
in the supported architectures page on the Web site you might like to
mention "difficulties" with A7000+s  (unless they've been fixed and I've
missed it...)

Cheers,
David.

PS - Unless anyone gets to it before me, I still intend to try to get
Linux running on my machine, when I have the disk space...

---

From: "Neil A. Carson" <[email-masked]>
Date: Sat, 04 Jul 1998 17:17:24 +0100

I believe that all A7000s and 7000+s have the first RAM bank in fact
present,although on some machines it is very very very small. Certainly
it was a bit too small for NetBSD + static structures etc AFAIR. I might
be wrong though.

-- 
Neil A. Carson

---

From: Philip Blundell <[email-masked]>
Date: Sat, 04 Jul 1998 22:03:53 +0100

>it was a bit too small for NetBSD + static structures etc AFAIR. I might

It would be quite possible (though not completely trivial) to fix the kernel 
so that you could run it out of either DRAM bank.  The only tricky bit would 
be for head.S to work out where it was running and behave accordingly.  
Whether it's worth doing is another question.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 4 Jul 1998 22:40:45 +0100 (BST)

> Whether it's worth doing is another question.

No Phil.  Please read my previous mails that talk about the self-decompressing
code.
   _____

---

From: Philip Blundell <[email-masked]>
Date: Sun, 05 Jul 1998 10:07:47 +0100

>No Phil.  Please read my previous mails that talk about the self-decompressing

Your previous mails don't seem to have made it here (at least not yet) so I'm 
just guessing at what you probably said.  However, I stand by my position that 
it would be possible.

1. We could say that you should just not use compressed kernels on such 
machines.  If !Linux can't already load vmlinux files it wouldn't take much to 
teach it to do so.  Since head-armv.S turns the MMU on as one of its first 
actions it wouldn't be hard to have it cope with the RAM being in a different 
place.

2. It would be possible to compile misc.c as PIC and hence let it run at any 
address.  Remember that any compiler that can build 2.1 probably supports PIC.

3. We could turn the MMU on for the duration of decompression and let head.S 
set up a minimal page table (just a few section mappings to get the first few 
megabytes of RAM mapped) to hide the differences.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 5 Jul 1998 17:15:46 +0100 (BST)

> just guessing at what you probably said.  However, I stand by my position that 

I for one will not be distributing any kernels that are not self-decompresssing.

> actions it wouldn't be hard to have it cope with the RAM being in a different 

!Linux can cope with the vmlinux files perfectly well.

> address.  Remember that any compiler that can build 2.1 probably supports PIC.

That was my original intention, however until I'm totally happy with the new
ELF compilers (I have to be to keep a known good base for the kernel work),
I don't see this happening before 2.2.

> megabytes of RAM mapped) to hide the differences.

See previous mail about decompressor code being processor independent.
   _____