Subject: RE: NFS root mounting of Assabet's filesystem

From: Jeff Sutherland <[email-masked]>
Date: Thu, 6 Jul 2000 14:05:17 -0400

> .... I have a slightly off-topic configuration
> question however: When the NFS root filesystem is first mounted (at the
end
> of do_basic_setup() in init/main.c) it is mounted as read only.

Use the command line "root=/dev/nfs rw" to the kernel.

	-- Dan

Thanks, Dan, that did it!

Mark suggested:

mount -o remount,rw <mount point>

which 'appeared' to work (telinit 1 first, note), yet had no effect.
Unmounting, then re-mounting also did not fix it.

I am working on a HOWTO for NFS root mounting SA1100-based devices.  For
draft copies, comments, flames, etc., please email me privately off-list.

Thanks!
//Jeff
mailto:[email-masked]

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

---

From: Dan Malek <[email-masked]>
Date: Thu, 06 Jul 2000 14:27:54 -0400

> mount -o remount,rw <mount point>

Hmmm....If <mount point> is '/', that should have worked as well.

> I am working on a HOWTO for NFS root mounting SA1100-based devices.

A little off topic, but I needed to say this anyway.

I have been requested to create a bootable image for SA like I did
for the embedded PowerPC port.  This is a compressed image that has
the initrd attached, and can be flashed into rom.  You just jump to
the first instruction of the image, it relocates, uncompresses, starts
the kernel and mounts the ram disk.  If there are some comments about
this, please let me know.

	-- Dan

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 6 Jul 2000 20:53:38 +0100 (BST)

> this, please let me know.

Hmm, its very very complicated, especially since there is no "standard"
memory map that you can rely on.  Really, you can not relocate the
kernel from the point where the boot loader loaded it without running
into many problems.

Also, the size of the kernel + size of initrd is likely to overflow
the amount of memory available in the first bank of RAM on banked RAM
machines.

About the only thing that can be considered is to relocate the initrd
to some other address, and hope it exists...
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Dan Malek <[email-masked]>
Date: Thu, 06 Jul 2000 16:48:01 -0400

Russell King - ARM Linux Admin wrote:

> Hmm, its very very complicated,

But....does this sound useful, or am I missing some other obvious
way to do this?  Should I have paid attention to the BLOB postings :-)?

> ..... especially since there is no "standard"

I don't relocate anything.  I'll explain.  Hit the big delete if you
aren't interested (no, not you Russell :-).  First, I don't understand
why sometimes you load the image at a low address, uncompress into a
high address, then copy back to the low address.  Other times you load
the image into the high address and uncompress into the low address.
I would always do the latter.  The uncompress code can either be
written to run at any address, or it can relocate itself to a specific
memory address.  This is what I would reloate if necessary.  For example.
If the "head.S" and "misc.c" functions are linked to 0xc0200000, and
are actually stored in flash, I would have a couple of lines of code that
discovers this condition and copies the code to 0xc0200000 and executes
from there.  Then just pass the pointers into decompress_kernel and
everything should uncompress properly.  You can attach the compressed
initrd to the same zImage, and have misc.c determine the location and
size of this.  It can pass this into the kernel.  You get one image
that can be loaded using your favorite method, and when you are happy
with it, the exact same set of bits can be flashed.  The Linux kernel
requires the compressed ram disk is in ram because it deallocates
the pages when finished.  If necessary (and I don't yet understand this),
misc.c can copy the image from the flash to another bank of ram.  I
guess some (or all) StrongARM memory isn't necessary contiguous?

Compressed ram disks aren't usually that big (1.5 to 2 Mbytes or so).
If the first ram bank is at least 4 Mbytes, this should work fine.

You just need to add a few smarts to functions in misc.c.  I also
like the ability to get an interactive command prompt here so you can
modify kernel command line paramters at this point.

OK.  I am ready to learn.  Teach me what I need to know to either make
this work or forget about it.

Thanks.

	-- Dan

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 6 Jul 2000 22:16:38 +0100 (BST)

> way to do this?  Should I have paid attention to the BLOB postings :-)?

Don't get me wrong - I'm not saying that its bad.  I'm just mentioning
that its a little more complicated.  The reason I haven't done it yet
is that there are more important things I have to do, and its going to
take a lot of thinking to get the right method that works.

> First, I don't understand why sometimes you load the image at a low
> address, uncompress into a high address, then copy back to the low
> address.  Other times you load the image into the high address and
> uncompress into the low address.

I'm not exactly sure what you mean here.  There are many different ARM
machines which have their RAM located at a variety of different places.
For instance, RiscPCs have DRAM in the range 0x10000000 to 0x20000000,
but in 4 banks, whereas EBSAs and other SA110-based machines have it
located at 0x00000000 in a contiguous chunk.  SA11x0-based machines
can have the memory located around 0xc0000000 to 0xe0000000, or even
in the SRAM space (sorry, don't have the physical addresses to hand).

All this means that head.S ends up being compiled to run at many
different places depending on the architecture.

Oh, and the kernel is always decompressed to the RAM directly following
the image, and then is copied back down to the "correct" RAM location
for calling it.

The reason we need this is where you have a 2MB bank 0 on a RiscPC or
similar machine - there is not really enough memory to place the
compressed kernel at the 1MB mark and hope that during decompression
that it doesn't overwrite the code doing the decompression.  (In fact,
this probably means that in this situation, a combined initrd/kernel
solution is not going to work.

> memory address.

Note that the head.S code is already written to be mostly relocatable.
(it requires a little more work around the ldmia instruction to fix this).
The misc.c code is a little more of a headache though - if you compile
it up -fPIC, then you need to fix up the relocations at run time.

This is not impossible, but the kernel has already been modified such
that it doesn't write into any part of the image during decompression.
This is required for the situation where the decompressor is run from
flash directly - flash devices don't generally like having random writes
directed at them.

> I guess some (or all) StrongARM memory isn't necessary contiguous?

Correct.  It depends on the machine you're talking about.

> modify kernel command line paramters at this point.

Really, the way this is done on other architectures (and I'm talking
generally) is that the loader provides this functionality.  On ARM,
we do have a generic parameter block where things like parameter lines
can be passed.

Unfortunately, not all ARM architectures use this. ;(
   _____

---

From: Dan Malek <[email-masked]>
Date: Thu, 06 Jul 2000 17:34:44 -0400

Russell King - ARM Linux Admin wrote:

> Don't get me wrong - I'm not saying that its bad.

I know.  I understand.  You gave me lots to think about.

> ....  The reason I haven't done it yet
> is that there are more important things I have to do,

OK.  I'll read the to-do list :-).

I will experiment with the couple of boards I have (Assabet and
BrightStar Engineering) and at least try to provide something on
those systems (since they asked for this).  I'll park it on a server
someplace and you canpick and choose from it when you wish.

Thanks for the help and information.

	-- Dan