Subject: mtools V3.6

From: Stefan Hanske <[email-masked]>
Date: Mon, 25 May 1998 15:55:37 +0200 (METDST)

Hi

here is a little patch that should allow mtools 3.6 to compile under 
ARMLinux. If you take a look at it you will possibly know what I mean 
with gcc's PACKED bug. It doesn't layout the struct vfat_subentry the way 
it's meant to be. And because the struct is written to disc as is, mtools 
checks the size of all important structs first. I compiled mtools under 
AIX and PC-Linux and they didn't have the problems.

The structure expects to have struct unicode_char (sizeof(...)=2) 
inserted correctly, but instead of 2 bytes it takes 4 bytes when being 
inserted in vfat_subentry. By adressing it as *char[index] this is avoided.

Bye bye ...

----------------------------------------------------------
|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...				 |
----------------------------------------------------------
diff -urN mtools-3.6/file_name.c mtools-3.6.modified/file_name.c
--- mtools-3.6/file_name.c	Thu Apr  3 07:24:25 1997
+++ mtools-3.6.modified/file_name.c	Sun May 24 05:27:43 1998
@@ -177,6 +177,7 @@

+#ifndef arm
 int unicode_read(struct unicode_char *in, char *out, int num)
 {
 	int j;
@@ -220,3 +221,48 @@
 	}
 	return num;
 }
+
+#else
+
+int unicode_read(char *in, char *out, int num)
+{
+	        int j;
+
+		for (j=0; j<num; ++j) {
+		if (in[2*j+1])
+			*out = '_';
+		else
+			*out = in[2*j];
+		++out;
+	}
+	return num;
+}
+
+/* If null encountered, set *end to 0x40 and write nulls rest of way
+ * 950820: Win95 does not like this!  It complains about bad characters.
+ * So, instead: If null encountered, set *end to 0x40, write the null, and
+ * write 0xff the rest of the way (that is what Win95 seems to do; hopefully
+ * that will make it happy)
+ */
+/* Always return num */
+int unicode_write(char *in, char *out, int num, int *end_p)
+{
+	        int j;
+
+		for (j=0; j<num; ++j) {
+		out[j*2+1] = '\0';      /* Hard coded to ASCII */
+		if (*end_p)
+		        /* Fill with 0xff */
+                        out[2*j+1] = out[2*j] = (char) 0xff;
+                else {
+                        out[2*j] = *in;
+                        if (! *in) {
+				*end_p = VSE_LAST;
+			}
+                }
+
+		++in;
+        }
+        return num;
+}
+#endif
diff -urN mtools-3.6/vfat.h mtools-3.6.modified/vfat.h
--- mtools-3.6/vfat.h	Tue Feb 18 18:32:39 1997
+++ mtools-3.6.modified/vfat.h	Sun May 24 05:45:21 1998
@@ -26,14 +26,26 @@
 
 struct vfat_subentry {
 	unsigned char id;		/* 0x40 = last; & 0x1f = VSE ID */
+#ifndef arm
 	struct unicode_char text1[VSE1SIZE] PACKED;
+#else
+	char text1[10];
+#endif
 	unsigned char attribute;	/* 0x0f for VFAT */
 	unsigned char hash1;		/* Always 0? */
 	unsigned char sum;		/* Checksum of short name */
+#ifndef arm
 	struct unicode_char text2[VSE2SIZE] PACKED;
+#else
+	char text2[12];
+#endif
 	unsigned char sector_l;		/* 0 for VFAT */
 	unsigned char sector_u;		/* 0 for VFAT */
+#ifndef arm
 	struct unicode_char text3[VSE3SIZE] PACKED;
+#else
+	char text3[4];
+#endif
 };
 
 /* Enough size for a worst case number of full VSEs plus a null */
@@ -70,9 +82,14 @@
 
 void clear_vfat(struct vfat_state  *);
 int check_vfat(struct vfat_state *v, struct directory *dir);
-int unicode_read(struct unicode_char *, char *, int num);
-int unicode_write(char *, struct unicode_char *, int num, int *end);
-unsigned char sum_shortname(char *);
+#ifndef arm
+  int unicode_read(struct unicode_char *, char *, int num);
+  int unicode_write(char *, struct unicode_char *, int num, int *end);
+#else
+  int unicode_read(char *, char *, int num);
+  int unicode_write(char *, char *, int num, int *end);
+#endif
+  unsigned char sum_shortname(char *);
 int write_vfat(Stream_t *, char *, char *, int);
 void clear_vses(Stream_t *, int, size_t);
 void autorename_short(char *, int);

---

From: dooby <[email-masked]>
Date: Tue, 26 May 1998 09:17:43 +0100 (BST)

Hi,

I tried compiling a very simple 'Hello World' type program, and got this...

miracle:~/mycprog# gcc myne.c
Internal error: Oops - address exception: 403
CPU: 0
pc : [<01a28344>]
lr : [<49a28347>]
sp : 026c2210  ip : 026c2218  fp : 00000000
r10: 01a2dfd0  r9 : 20092894  r8 : 00000007
r7 : 00000000  r6 : 00000000  r5 : 0017f100  r4 : 00000000
r3 : 0215f910  r2 : 02434018  r1 : 01a2e058  r0 : 02153e28
Flags: nZcv  IRQs off  FIQs on  Mode SVC_26
Process cc1 (pid: 214, stackpage=026c125c)
Stack:
Code: pc not in code space
gcc: Internal compiler error: program cc1 got fatal signal 7
miracle:~/mycprog#

I am currently using the latest 2.0.31 A5000 kernel.

I actually did the RedHat install on a SA RPC - could this be the problem? If so, can I just reinstall the binutils, gcc, etc. bits (and how?). If not,
can some kind soul compile and send me working binaries of everything I need to compile stuff myself please?

My RedHat install tree contains this package :-
  RedHat/RPMS/binutils-2.7-1a2.arm.rpm

The machine then proceeds to bring up similar messages to the above when
trying to run almost anything - including rebooting, and is generally
stuffed.

Any ideas anyone? TIA,

dooby

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

---

From: dooby <[email-masked]>
Date: Tue, 26 May 1998 09:16:21 +0100 (BST)

Hi all,

I have tried setting up Linux (with loadmap) to use a kernel on my root
partition, but when I try to run !Linux I get the message

Error: unable to access sectors 0x1A3966 above 0xFFFFF

My /etc/boot.conf file is as follows :-

riscos {
	name = "Risc OS";
};

kernel {
	name = "Linux 2.0.31";
	path = "/vmlinuz";
	root = "/dev/hdb3";
	ramdisk = 0;
	flags = readonly;
};

This also causes IscaFS to say 'This partition is not readable by your
version of Filecore. error when reading
ADFS::Utils.Linux.IscaFS0-04.Support.GetPartns.0'.

I have used PartMan 1.11 to set up partitions on ADFS 5 :-

Partition  Start     End      Size    Type
    1	         0  1046303   511 MB Filecore
    2	   1046304  1046305     1 KB Linux Table
    3	   1046306  2092834   511 MB Linux Native (root)
    4	   2092835  3077923   481 MB Linux Native (usr)
    5	   3077924  3324383   120 MB Linux Swap

I guess this is probably due to Risc OS 3.11 Filecore limitations? If this is
the case, is there any way of moving/reducing partitions such that I can access
the (smaller) partitions without a full re-install?

I briefly tried Clan's beta Filecore patch, but it didn't work, and I'm
not sure that it isn't overwritten by linux anyway...

Thanks for any help,

dooby

---

From: dooby <[email-masked]>
Date: Tue, 26 May 1998 09:20:59 +0100 (BST)

Oh dear - me again with another niggle ;-)

When Linux is starting up it says

Finding module dependencies .. /lib/modules/2.0.33/modules.dep

then is sulks 'cos it can't find that file.

I changed the 2.0.33 to 2.0.31 (my kernel version) and got lots of lovely
'unresolved symbol' errors about various modules.

Can I get the 2.0.31 version os the file anywhere? Is that the solution
anyway?

Cheers,

dooby

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 26 May 1998 12:43:59 +0100 (BST)

dooby
> Error: unable to access sectors 0x1A3966 above 0xFFFFF

Yes.  Your filecore is incapable of accessing past the first 512MB.  This
is not fixable by anyone except Acorn releasing a new filecore for RISC OS
3.1, which there is insufficient demand for.

> ADFS::Utils.Linux.IscaFS0-04.Support.GetPartns.0'.

That's correct.  It's defined in the documentation.

> the (smaller) partitions without a full re-install?

Not really.  You could reformat the filecore and put a new linux partition
in below the linux table.  Maybe.  I wouldn't like to try it though.
What you can do is boot with -bootkernel and then specify `root=/dev/hda3
ro' Maybe I'll rewrite some of the documentation post-exams to make this
more clear.  (And reread other bits of it so I understand some of the
options I don't use.. my hazy memory tells me it should be possible to
boot with a kernel somewhere else without having to enter those extra
options elsewhere..)

-- 
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 26 May 1998 12:46:37 +0100 (BST)

dooby
> then is sulks 'cos it can't find that file.

The command it's executing reads your kernel version.  You're using 2.0.33.

> Can I get the 2.0.31 version os the file anywhere? Is that the solution

you need to run mkdep.  Possibly telling it to `fake' which kernel
version you have.  `man mkdep' for more details.

---

From: John Tytgat <[email-masked]>
Date: Tue, 26 May 1998 14:07:10 +0200

> 3.1, which there is insufficient demand for.

But don't you also need to upgrade the ADFS/SCSI modules which are
>512MB aware (ie. which implement the new FileCore calls) ? I thought
that an upgrade of FileCore is not sufficent enough.

John.
-- 
John Tytgat                          And Bill said: "What's a network?"
[email-masked]        http://www.idg.co.nz/interview/Hauser.html
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Phil Norman <[email-masked]>
Date: Tue, 26 May 1998 13:31:05 +0100 (BST)

> boot with a kernel somewhere else without having to enter those extra

There is a way to hack the bootloader so it automatically assumes what 
extra arguments you want it to assume.  I did it to mine in the following 
manner:

1:	Ran the bootloader through the debugger and got it to decompress 
itself, and then used the *command thing from the debugger's main menu to 
*save the now-decompressed !RunImage (*save $.foo 8000 <whatever the 
final address in the current wimpslot is> - use the debugger's window to 
scroll down to the end if application memory to find this out).

2:	Load the decompressed !RunImage into your favourite text editor 
and clip as much of the end off as you feel safe clipping (most of the 
wimpslot you saved will be data or random garbage, which can be safely 
removed without changing the way the program runs).

3:	With your newly-shortened, decompressed !RI still in the text 
editor, search for the instruction (you'll have to be in disassembly mode 
to do this) OS_ReadLine and replace it with a branch to the end of the 
binary, where you should insert the following:

	STMDB	r13!,{r0-r8,r14}
	ADR	r1,foo
	LDMIA	r1,{r2-r5}
	STMIA	r0,{r2-r5}
	LDMIA	r13!,{r0-r8,pc}^
.foo
	EQUS	"root=/dev/hda3"+CHR$10
	ALIGN

Now, running the bootloader with "-bootkernel 
ADFS::4.$.ARMLinux.kernels.wibble" should automatically assume that 
/dev/hda3 is the root partition.  The operation of the program will be 
exactly as if you had typed "root=/dev/hda3" at the prompt yourself.

SANITY WARNING:  DO NOT attempt this unless you are confident with 
hacking about with binaries.

SANITY WARNING #2:  KEEP A COPY OF THE ORIGINAL !RunImage!!!

However, if you do know what you're doing and hack it correctly, it 
should work fine.  Mine currently works like a dream, and I've even got 
an alias set up so all I have to do to boot into linux is to type *linux 
at the command prompt :-).

Enjoy your hacking should you feel up to it,
Phil

-- 
Rule of programming #3: The number of bugs which exist in a program is
	equal to the square of the number of bugs which you think exist.

Phil Norman, mailing from Exeter University.
email:	[email-masked]
URL:	http://newton.ex.ac.uk/general/ug/norman

---

From: Philip Blundell <[email-masked]>
Date: Tue, 26 May 1998 14:05:09 +0100

>extra arguments you want it to assume.  I did it to mine in the following 

Ye gods.  Russell, how about releasing the source to the thing?

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 26 May 1998 19:46:47 +0100 (BST)

> version you have.  `man mkdep' for more details.

Thats depmod -a <other-options>, and man depmod.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Tue, 26 May 1998 19:02:18 +0100 (BST)

> Error: unable to access sectors 0x1A3966 above 0xFFFFF

Looks like old filecore to me ;)

> the (smaller) partitions without a full re-install?

Not currently.
   _____

---

From: Tony Houghton <[email-masked]>
Date: Tue, 26 May 1998 18:33:01 +0100

In message <Pine.SGI.3.91.980526132046.18866C-100000@hebe>

> extra arguments you want it to assume.  I did it to mine in the following

That's handy, because I'm having to boot that way because loadmap
crashes on my SA RPC and nobody seems to know why. Will it crash if I've
got something wrong with /etc/boot.conf ? I've also got the impression
that it's ARM-sepcific and I don't know its purpose. Could someone
kindly explain it or perhaps point me to the right message to look up in
the archive if it's been explained before?

> scroll down to the end if application memory to find this out).

That's a complicated way to unsqueeze it (I presume the compression is
Squeeze). If you've got !Patch you should have !Patch.Modules.UnSqueeze.
Load that and type "*unsqueeze <Linux$Dir>.!RunImage".

-- 
  \_________________
                    \  http://homepages.tcp.co.uk/~tonyh/
   The Curling Pages \ The home of WinEd, Bombz and POPstar for RISC OS
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

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

> lr : [<49a28347>]

That looks like it's in the FPEmulator module - what version of the fpemulator
are you using, and what other modules do you have loaded (lsmod)?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Tue, 26 May 1998 20:01:15 +0100 (BST)

> Finding module dependencies .. /lib/modules/2.0.33/modules.dep

Don't you mean lib/modules/2.0.31/modules.dep if you're using the 2.0.31
kernel?

   _____

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 26 May 1998 19:52:02 +0100 (BST)

> Ye gods.  Russell, how about releasing the source to the thing?

Once the bl**dy new PartMan has been tested properly - it's all using
the same code.

Suggestions are apprechiated how to handle multiple-concurrent
development for RiscOS.  As far as I am concerned, RiscOS has a
single-person development model *only* (only one person can have
the source and modify it).

There is a reason for tight control on this - common code is used in:
1. Linux fdisk
2. !Linux
3. !PartMan

I will not distribute the sources separately, so until I'm happy with
this final alpha version, it's not going anywhere.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 26 May 1998 22:48:50 +0100 (BST)

Phil Norman
> extra arguments you want it to assume.  I did it to mine in the following 

Phil, you're a sick, evil and twisted individual ;-)  Surely it's simpler
to compile your own kernel, having changed the default settings for
ROOT_DEV in the Makefile

---

From: Stefan Hanske <[email-masked]>
Date: Wed, 27 May 1998 19:16:17 +0200 (METDST)

> trying to run almost anything - including rebooting, and is generally

Yes, you're right. The problem is the fpemulator(s) since there're two of
them. One for older ARM machines and one for RPC's. There is a link set up
in /lib/modules/misc (I think, try looking for fpem* in /lib/modules).
Since you installed on a SA RPC the link will be set to version 4 of fpem.
You need to change this link to point to fpem version 2.87.