RISC OS port

RISC OS port

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Hello, all. When writing tests for GRUB I've noticed that 'acorn'
partition table wasn't testes at all, digging deeper I found out that it
was part of RISC OS port proposed by Timothy Baldwin in 2005. I haven't
looked through complete port yet but what is its target machine and
would there be benefits of resurecting those patches on top of current
ARM patches?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

RISC OS port

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

During the past few months I have been working on a port to RISC OS an ARM 
processors. It has reached the point where it can boot Linux, and IMO is 
nearly ready to be included in CVS. It does not support to booting of 
compressed Linux kernels as the decompression code has not been updated to 
the new parameter passing convention.

It includes support to access filesystems though the RISC OS filesystem API, 
which error numbers should be returned in case of an error?

I propose returning GRUB_ERR_FILE_NOT_FOUND when RISC OS return a file not 
found error, and in other cases returning an error number based on what Grub 
is trying to do, ie one of:

GRUB_ERR_FILE_CLOSE_ERROR
GRUB_ERR_FILE_OPEN_ERROR
GRUB_ERR_FILE_READ_ERROR
GRUB_ERR_DIR_READ_ERROR

The other ends which need tidying up before inclusion in CVS are:
Write a changelog
Fix copyright notices
Write support for ARMv4 (eg. StrongARM) and ARMv5 processors (eg. XScale).
Fix the arrow keys

What codes should the arrow keys return? The openfirmware and PC drivers 
disagree.

Since the patch 138KiB large I have put it on the web at:
http://www.majoroak.f2s.com/tim/grub/downloads/patch2.diff

It's sha1sum is: 7b40a537ce5d110eaf3ea73801853fe198c8841f
It's md5sum is:  20ccbc634b13d86c2643adfed95d36a7

TODO list:
Support access to RISC OS files not on (or symlinked from) devices supported 
by Grub.
Support loading of Linux initrds.
Write an installer and updater.
Possibly support attaching modules to the kernel.

-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

> During the past few months I have been working on a port to RISC OS an ARM 
> processors. It has reached the point where it can boot Linux, and IMO is 
> nearly ready to be included in CVS. It does not support to booting of 
> compressed Linux kernels as the decompression code has not been updated to 
> the new parameter passing convention.

That is really nice!  Can you get the GRUB menu to work, etc?

How about module loading?  I noticed you wrote some code for that
too...

I noticed you used a lot of assembler.  Isn't it possible to minimize
the use of assembler somehow?  If that is not possible, no problem.

> It includes support to access filesystems though the RISC OS filesystem API, 
> which error numbers should be returned in case of an error?

I remember a discussion about this...  I noticed you implemented some
disk access code.  Is it possible to access GNU/Linux partitions?

Is it possible to write support for the filesystem used on RISC OS?  I
can help you with that, if you want that.

> The other ends which need tidying up before inclusion in CVS are:
> Write a changelog
> Fix copyright notices
> Write support for ARMv4 (eg. StrongARM) and ARMv5 processors (eg. XScale).
> Fix the arrow keys

Nice.  Can you please split up the patch somehow?  And please make
sure you follow the GCS.  That is an important requirement for patches
for GRUB.  If you can do that, it will be easier for me to proof read
the patch(es) before it can be applied.

> What codes should the arrow keys return? The openfirmware and PC drivers 
> disagree.

Perhaps it will be easier if there is one file that defines the
available keys.  Now it is arch dependent.  Anyway, I remember there
is some room for improvement...

>
> TODO list:
> Support access to RISC OS files not on (or symlinked from) devices supported 
> by Grub.

Don't worry about cross filesystem symlinks.

> Possibly support attaching modules to the kernel.

Attaching modules to the kernel?

Thanks,
Marco

Re: RISC OS port

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

On Tuesday 23 Nov 2004 18:03, Marco Gerards wrote:
> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
> > During the past few months I have been working on a port to RISC OS an
> > ARM processors. It has reached the point where it can boot Linux, and IMO
> > is nearly ready to be included in CVS. It does not support to booting of
> > compressed Linux kernels as the decompression code has not been updated
> > to the new parameter passing convention.
>
> That is really nice!  Can you get the GRUB menu to work, etc?

I can't get menu to work on PC, grub-emu (which crashes), or RISC OS. I've 
tried with clean CVS source.

> How about module loading?  I noticed you wrote some code for that
> too...

Works. Not yet tested on processors with separate instruction and data caches, 
as I don't have any.

> I noticed you used a lot of assembler.  Isn't it possible to minimize
> the use of assembler somehow?  If that is not possible, no problem.

I've rewritten the RISC OS filesystem access code to use the C library, and 
I've rewritten some of the console code in C.

>
> > It includes support to access filesystems though the RISC OS filesystem
> > API, which error numbers should be returned in case of an error?
>
> I remember a discussion about this...  I noticed you implemented some
> disk access code.  Is it possible to access GNU/Linux partitions?

Not on the standard IDE interface, on a disc shared with RISC OS, because a 
partition module has yet to be written. 

> Is it possible to write support for the filesystem used on RISC OS?  I
> can help you with that, if you want that.

Attempting to use a filesystem handler within Grub would be unreliable due the 
filesystem also being mounted read/write.

> > The other ends which need tidying up before inclusion in CVS are:
> > Write a changelog
> > Fix copyright notices

Still to do.

> > Write support for ARMv4 (eg. StrongARM) and ARMv5 processors (eg.
> > XScale). Fix the arrow keys

Done. And ARMv6 processors hopefully.

> Nice.  Can you please split up the patch somehow? 

I'll remove the module loader fixes I have already submitted.
I'll separate out the changes to the existing files, and the Linux loader.

The majority of can't be easily split up into independent patches. Shall I 
split them up into a set of patches which have to be applied together?

> And please make sure you follow the GCS.

include/grub/arm/linux_setup.h is an unmodified file from Linux 2.6.9 
(include/asm-arm/setup.h).

Uppercase is used thoughout for the name of RISC OS, as "risc_os" could be 
interpreted as a reference to the operating system called "riscos".

May I use the standard names for (ROM resident) C library globals?

May the official RISC OS system call names in include/grub/arm/RISC_OS/swis.h 
stay? The file is only included in assembler, and to change the names would 
be confusing.

Apart from a lack of comments and a few lower case macros, is there anything 
which obviously needs fixing?

> > What codes should the arrow keys return? The openfirmware and PC drivers
> > disagree.
>
> Perhaps it will be easier if there is one file that defines the
> available keys.  Now it is arch dependent.  Anyway, I remember there
> is some room for improvement...

I'll copy Open Firmware for now.

> > Possibly support attaching modules to the kernel.
>
> Attaching modules to the kernel?

Like grub-mkimage does on PCs.

-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

> On Tuesday 23 Nov 2004 18:03, Marco Gerards wrote:
>> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
>> > During the past few months I have been working on a port to RISC OS an
>> > ARM processors. It has reached the point where it can boot Linux, and IMO
>> > is nearly ready to be included in CVS. It does not support to booting of
>> > compressed Linux kernels as the decompression code has not been updated
>> > to the new parameter passing convention.
>>
>> That is really nice!  Can you get the GRUB menu to work, etc?
>
> I can't get menu to work on PC, grub-emu (which crashes), or RISC OS. I've 
> tried with clean CVS source.

Just place grub.cfg in your prefix path.  You just have to run "set"
to find out what the prefix is.

>> > It includes support to access filesystems though the RISC OS filesystem
>> > API, which error numbers should be returned in case of an error?
>>
>> I remember a discussion about this...  I noticed you implemented some
>> disk access code.  Is it possible to access GNU/Linux partitions?
>
> Not on the standard IDE interface, on a disc shared with RISC OS, because a 
> partition module has yet to be written. 

Oh, right.  That should not be too hard, from my experience.

>> Is it possible to write support for the filesystem used on RISC OS?  I
>> can help you with that, if you want that.
>
> Attempting to use a filesystem handler within Grub would be unreliable due the 
> filesystem also being mounted read/write.

Usually a filesystem is still usable readonly when it is mounted rw.
This is the same as it is for grub-emu, for example.  And I assume
some filesystems are not mounted, like the ext2 partitions or so.

>> Nice.  Can you please split up the patch somehow? 
>
> I'll remove the module loader fixes I have already submitted.
> I'll separate out the changes to the existing files, and the Linux loader.

Ok, that sounds nice.  You could even do the same for the filesystem
and disk stuff, for example.  As far as I am concerned it does not
have to work after the first commit, as long as it doesn't break
anything.  I wonder how the other developers think about that.

> The majority of can't be easily split up into independent patches. Shall I 
> split them up into a set of patches which have to be applied together?

That would not make much sense, I think.

>> And please make sure you follow the GCS.
>
> include/grub/arm/linux_setup.h is an unmodified file from Linux 2.6.9 
> (include/asm-arm/setup.h).

IIRC copyright need to be assigned to the FSF for every change/file.
Okuji, how should we deal with such things?

> Uppercase is used thoughout for the name of RISC OS, as "risc_os" could be 
> interpreted as a reference to the operating system called "riscos".

Personally I do not like uppercase filenames at all.

> May I use the standard names for (ROM resident) C library globals?

Can you give an example of what you mean with that?

> May the official RISC OS system call names in include/grub/arm/RISC_OS/swis.h 
> stay? The file is only included in assembler, and to change the names would 
> be confusing.

Is it a copyrighted file which was not written by you?

> Apart from a lack of comments and a few lower case macros, is there anything 
> which obviously needs fixing?

What I said, please check for GCS related things like indentation.  If
you think it is all correct I can help you to find the issues.  When I
had a look at your patch, I spotted a few things that are not correct
according to the GCS.

>> > What codes should the arrow keys return? The openfirmware and PC drivers
>> > disagree.
>>
>> Perhaps it will be easier if there is one file that defines the
>> available keys.  Now it is arch dependent.  Anyway, I remember there
>> is some room for improvement...
>
> I'll copy Open Firmware for now.

Sure.

>> > Possibly support attaching modules to the kernel.
>>
>> Attaching modules to the kernel?
>
> Like grub-mkimage does on PCs.

Ok.  That's nice.

Thanks,
Marco

Re: RISC OS port

[Yoshinori K. Okuji]

On Friday 26 November 2004 11:18, Marco Gerards wrote:
> > include/grub/arm/linux_setup.h is an unmodified file from Linux
> > 2.6.9 (include/asm-arm/setup.h).
>
> IIRC copyright need to be assigned to the FSF for every change/file.
> Okuji, how should we deal with such things?

http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries

Okuji

Re: RISC OS port

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

On Friday 26 Nov 2004 10:18, Marco Gerards wrote:
> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
> > On Tuesday 23 Nov 2004 18:03, Marco Gerards wrote:


> > Attempting to use a filesystem handler within Grub would be unreliable
> > due the filesystem also being mounted read/write.
>
> Usually a filesystem is still usable readonly when it is mounted rw.
> This is the same as it is for grub-emu, for example.

The auto-defragment feature makes FileCore/ADFS, the main disc-based 
filesystem of RISC OS, one of the exceptions.

> And I assume 
> some filesystems are not mounted, like the ext2 partitions or so.
>
> >> Nice.  Can you please split up the patch somehow?
> >
> > I'll remove the module loader fixes I have already submitted.
> > I'll separate out the changes to the existing files, and the Linux
> > loader.
>
> Ok, that sounds nice.  You could even do the same for the filesystem
> and disk stuff, for example.  As far as I am concerned it does not
> have to work after the first commit, as long as it doesn't break
> anything.  I wonder how the other developers think about that.

Here is the split I propose:

0. Dynamic loader fixes.
1. Portability fixes and configure.ac changes.
2. Console and core features, so that rescue mode works.
3. Disc support.
4. Filesystem API support.
5. Physical memory abstraction layer and RISC OS shutdown.
6. Hardware identification.
7. Linux loader.

> > The majority of can't be easily split up into independent patches. Shall
> > I split them up into a set of patches which have to be applied together?
>
> That would not make much sense, I think.

In the sense that the RISC OS port wouldn't compile if only some of them were 
applied.

> > May I use the standard names for (ROM resident) C library globals?
>
> Can you give an example of what you mean with that?

The RISC OS shared C library does not export its globals by name, instead the 
functions are accessed by a table of branch instructions in the client's (eg 
GRUB) bss section. Likewise the C library's static data (including errno, 
stdin, stdout, etc) also resides in the client's bss area and is accessed by 
the C library via a pointer in a register.

Normally the C library is used by linking the client with the library stubs 
which provide the binding between the names of globals and their addresses. 
GRUB does not use the stubs because:

1. They are in AOF instead of ELF.
2. None of the free stubs support using an old library with code compiled to 
the new ABI (APCS-32). The old ABI (APCS-26) does not work on new processors.
3. It would be an unreasonable build time dependncy.

Instead part of functionality of the stubs is included in 
kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
for them. For clairity I suggest we use the standard names, as opposed to 
prefixing the names with grub_RISC_OS_ or simular.

GRUB uses the following functions from the C library at the moment:
malloc
free
realloc
fopen
fclose
fread
fseek
ftell


>
> > May the official RISC OS system call names in
> > include/grub/arm/RISC_OS/swis.h stay? The file is only included in
> > assembler, and to change the names would be confusing.
>
> Is it a copyrighted file which was not written by you?

No, I wrote the file myself copying the names and numbers from the 
documentation.


-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RISC OS port

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 7609 bytes --]

On Saturday 27 Nov 2004 01:36, I wrote:

> 1. Portability fixes and configure.ac changes.

Here they are. However cross-compiling is broken in that
the utilities are only built for the build system, without
this patch they are only built for the host system. Either
way, the result is not a complete installation.

I propose to solve this problem by running configure twice
when cross-compiling, once for the host, once for the build
system. This could be done by adding these make rules:

build/%: build/Makefile
 cd build && $(MAKE) $*
 touch $@

build/Makefile: $(srcdir)/configure
 cd build && $(srcdir)/configure --host=$(build) --target=$(host)

Define BUILD to "build/" when cross compiling or to ""
when not cross-compiling and prefix use of the utilites
in makefiles with $(BUILD).

Shall I do that?


diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/commands/cmp.c grub2-arm/commands/cmp.c
--- grub2-submitted/commands/cmp.c 2004-04-04 14:46:00.000000000 +0100
+++ grub2-arm/commands/cmp.c 2004-11-26 21:46:02.000000000 +0000
@@ -1,4 +1,4 @@
-/* cmd.c - command to cmp an operating system */
+/* cmd.c - command to compare two files. */
 /*
  *  GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 2003  Free Software Foundation, Inc.
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/configure.ac grub2-arm/configure.ac
--- grub2-submitted/configure.ac 2004-06-19 14:43:01.000000000 +0100
+++ grub2-arm/configure.ac 2004-11-26 21:46:02.000000000 +0000
@@ -23,12 +23,14 @@ AC_CANONICAL_HOST
 case "$host_cpu" in
   i[[3456]]86) host_cpu=i386 ;;
   powerpc) ;;
+  arm) ;;
   *) AC_MSG_ERROR([unsupported CPU type]) ;;
 esac
 
 case "$host_cpu"-"$host_vendor" in
   i386-*) host_vendor=pc ;;
   powerpc-*) host_vendor=ieee1275 ;;
+  arm-*) host_vendor=RISC_OS ;;
   *) AC_MSG_ERROR([unsupported machine type]) ;;
 esac
 
@@ -62,6 +64,15 @@ if test "x$default_CFLAGS" = xyes; then
     tmp_CFLAGS="$tmp_CFLAGS -O2 -fno-strength-reduce -fno-unroll-loops"
   fi
 
+  # C99.
+  AC_CACHE_CHECK([whether -std=gnu99 works], c99_flag, [
+    CFLAGS=-std=gnu99
+    AC_TRY_COMPILE(, , c99_flag=yes, c99_flag=no)
+  ])
+  if test "x$c99_flag" = xyes; then
+    tmp_CFLAGS="$tmp_CFLAGS -std=gnu99"
+  fi
+
   # Force no alignment to save space on i386.
   if test "x$host_cpu" = xi386; then
     AC_CACHE_CHECK([whether -falign-loops works], [falign_loop_flag], [
@@ -97,6 +108,10 @@ else
   AC_DEFINE([NESTED_FUNC_ATTR], [],[Catch gcc bug])
 fi
 
+if test "x$host_cpu" = xarm; then
+  AC_PATH_PROG(PERL, perl)
+fi
+
 AC_PROG_INSTALL
 AC_PROG_MAKE_SET
 AC_CHECK_TOOL(OBJCOPY, objcopy)
@@ -109,7 +124,7 @@ AC_CHECK_TOOL(LD, ld)
 AC_PATH_PROG(RUBY, ruby)
 
 # For cross-compiling.
-if test "x$build" = "x$host"; then
+if test "x$build" != "x$host"; then
   AC_CHECK_PROGS(BUILD_CC, [gcc egcs cc],
    [AC_MSG_ERROR([none of gcc, egcs and cc is found. set BUILD_CC manually.])])
 else
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/include/grub/disk.h grub2-arm/include/grub/disk.h
--- grub2-submitted/include/grub/disk.h 2004-10-02 11:28:45.000000000 +0100
+++ grub2-arm/include/grub/disk.h 2004-11-26 21:46:02.000000000 +0000
@@ -31,6 +31,7 @@ enum grub_disk_dev_id
   {
     GRUB_DISK_DEVICE_BIOSDISK_ID,
     GRUB_DISK_DEVICE_OFDISK_ID,
+    GRUB_DISK_DEVICE_FILECORE_ID,
   };
 
 struct grub_disk;
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/include/grub/err.h grub2-arm/include/grub/err.h
--- grub2-submitted/include/grub/err.h 2004-10-02 11:28:45.000000000 +0100
+++ grub2-arm/include/grub/err.h 2004-11-26 21:46:02.000000000 +0000
@@ -49,7 +49,10 @@ typedef enum
     GRUB_ERR_NO_KERNEL,
     GRUB_ERR_BAD_FONT,
     GRUB_ERR_NOT_IMPLEMENTED_YET,
-    GRUB_ERR_SYMLINK_LOOP
+    GRUB_ERR_SYMLINK_LOOP,
+    GRUB_ERR_FILE_CLOSE_ERROR,
+    GRUB_ERR_FILE_OPEN_ERROR,
+    GRUB_ERR_DIR_READ_ERROR
   }
 grub_err_t;
 
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/include/grub/misc.h grub2-arm/include/grub/misc.h
--- grub2-submitted/include/grub/misc.h 2004-11-19 00:55:52.000000000 +0000
+++ grub2-arm/include/grub/misc.h 2004-11-26 21:46:02.000000000 +0000
@@ -26,10 +26,11 @@
 #include <grub/symbol.h>
 #include <grub/err.h>
 
 /* XXX: If grub_memmove is too slow, we must implement grub_memcpy.  */
 #define grub_memcpy(d,s,n) grub_memmove ((d), (s), (n))
 
 void *EXPORT_FUNC(grub_memmove) (void *dest, const void *src, grub_size_t n);
+void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
 char *EXPORT_FUNC(grub_strcpy) (char *dest, const char *src);
 char *EXPORT_FUNC(grub_strncpy) (char *dest, const char *src, int c);
 char *EXPORT_FUNC(grub_stpcpy) (char *dest, const char *src);
@@ -53,6 +56,7 @@ unsigned long EXPORT_FUNC(grub_strtoul) 
 char *EXPORT_FUNC(grub_strdup) (const char *s);
 char *EXPORT_FUNC(grub_strndup) (const char *s, grub_size_t n);
 void *EXPORT_FUNC(grub_memset) (void *s, int c, grub_size_t n);
+void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
 grub_size_t EXPORT_FUNC(grub_strlen) (const char *s);
 int EXPORT_FUNC(grub_printf) (const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 int EXPORT_FUNC(grub_vprintf) (const char *fmt, va_list args);
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/include/grub/symbol.h grub2-arm/include/grub/symbol.h
--- grub2-submitted/include/grub/symbol.h 2004-06-19 14:43:01.000000000 +0100
+++ grub2-arm/include/grub/symbol.h 2004-11-26 21:46:02.000000000 +0000
@@ -29,8 +29,8 @@
 # define EXT_C(sym) sym
 #endif
 
-#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), @function ; EXT_C(x):
-#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), @object ; EXT_C(x):
+#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), "function" ; EXT_C(x):
+#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), "object" ; EXT_C(x):
 
 /* Mark an exported symbol.  */
 #define EXPORT_FUNC(x) x
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/kern/misc.c grub2-arm/kern/misc.c
--- grub2-submitted/kern/misc.c 2004-11-19 00:55:52.000000000 +0000
+++ grub2-arm/kern/misc.c 2004-11-26 21:46:02.000000000 +0000
@@ -45,8 +45,10 @@ grub_memmove (void *dest, const void *sr
   
   return dest;
 }
+
 void *memmove (void *dest, const void *src, grub_size_t n)
   __attribute__ ((alias ("grub_memmove")));
+
 /* GCC emits references to memcpy() for struct copies etc.  */
 void *memcpy (void *dest, const void *src, grub_size_t n)
   __attribute__ ((alias ("grub_memmove")));
@@ -294,7 +296,7 @@ grub_strtoul (const char *str, char **en
        str += 2;
      }
  }
-      else if (str[1] >= '0' && str[1] <= '7')
+      else if (base == 0 && str[1] >= '0' && str[1] <= '7')
  base = 8;
     }
   
diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/Makefile.in grub2-arm/Makefile.in
--- grub2-submitted/Makefile.in 2004-10-02 11:28:45.000000000 +0100
+++ grub2-arm/Makefile.in 2004-11-26 21:46:02.000000000 +0000
@@ -66,6 +66,7 @@ STRIP = @STRIP@
 NM = @NM@
 LD = @LD@
 RUBY = @RUBY@
+PERL = @PERL@
 
 ### General variables.
 


-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

> On Saturday 27 Nov 2004 01:36, I wrote:
>
>> 1. Portability fixes and configure.ac changes.
>
> Here they are. However cross-compiling is broken in that
> the utilities are only built for the build system, without
> this patch they are only built for the host system. Either
> way, the result is not a complete installation.

Ok.  I really hope someone else can have a look at this because I
don't know much about autoconf/automake, etc.  However, I am trying to
comment on your code wherever I can.

> I propose to solve this problem by running configure twice
> when cross-compiling, once for the host, once for the build
> system. This could be done by adding these make rules:
>
> build/%: build/Makefile
>  cd build && $(MAKE) $*
>  touch $@
>
> build/Makefile: $(srcdir)/configure
>  cd build && $(srcdir)/configure --host=$(build) --target=$(host)
>
> Define BUILD to "build/" when cross compiling or to ""
> when not cross-compiling and prefix use of the utilites
> in makefiles with $(BUILD).
>
> Shall I do that?

This does not look like a clean solution to me.  Normally this is not
required to do it like this, right?

Can you please make a changelog entry for this patch?

> +if test "x$host_cpu" = xarm; then
> +  AC_PATH_PROG(PERL, perl)
> +fi
> +

Why do you need perl?

> +    GRUB_ERR_FILE_CLOSE_ERROR,
> +    GRUB_ERR_FILE_OPEN_ERROR,
> +    GRUB_ERR_DIR_READ_ERROR

When are these errors triggered, btw?  Can't you use GRUB_ERR_BAD_FS
or GRUB_FS_BAD_FILE_TYPE instead?


> diff -purN -x '*.mk' -x '*~' -x autom4te.cache -x configure -x '.#*' -x CVS grub2-submitted/include/grub/misc.h grub2-arm/include/grub/misc.h
> --- grub2-submitted/include/grub/misc.h 2004-11-19 00:55:52.000000000 +0000
> +++ grub2-arm/include/grub/misc.h 2004-11-26 21:46:02.000000000 +0000

...

> +void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
> +void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);

Why do you want to do this?  Can't you just use grub_memcpy and
grub_memset instead?

> -#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), @function ; EXT_C(x):
> -#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), @object ; EXT_C(x):
> +#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), "function" ; EXT_C(x):
> +#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), "object" ; EXT_C(x):

Can you please explain this change?
>  }
> +
>  void *memmove (void *dest, const void *src, grub_size_t n)
>    __attribute__ ((alias ("grub_memmove")));
> +

Please watch out with adding white lines.



Does GRUB 2 still work on the PC after this patch is committed?

Thanks,
Marco

Re: RISC OS port

[Timothy Baldwin]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

On Friday 03 Dec 2004 13:07, Marco Gerards wrote:
> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
> 
> > On Saturday 27 Nov 2004 01:36, I wrote:
> >
> >> 1. Portability fixes and configure.ac changes.
> >
> > Here they are. However cross-compiling is broken in that
> > the utilities are only built for the build system, without
> > this patch they are only built for the host system. Either
> > way, the result is not a complete installation.
> 
> Ok.  I really hope someone else can have a look at this because I
> don't know much about autoconf/automake, etc.  However, I am trying to
> comment on your code wherever I can.
> 
> > I propose to solve this problem by running configure twice
> > when cross-compiling, once for the host, once for the build
> > system. This could be done by adding these make rules:
> >
> > build/%: build/Makefile
> >  cd build && $(MAKE) $*
> >  touch $@
> >
> > build/Makefile: $(srcdir)/configure
> >  cd build && $(srcdir)/configure --host=$(build) --target=$(host)
> >
> > Define BUILD to "build/" when cross compiling or to ""
> > when not cross-compiling and prefix use of the utilites
> > in makefiles with $(BUILD).
> >
> > Shall I do that?
> 
> This does not look like a clean solution to me.

> Normally this is not 
> required to do it like this, right?

The gcc package also uses multiple runs of configure.

You're right, genmoddep does not require the services of configure,
but then why was support for checking the build system compiler
added to configure.ac?

I suggest removing that support, and only use BUILD_CC for compiling
genmoddep. Support for building cross versions of the tools could be
retained by supporting configure's --target option. 

But for more complicated cases requiring the use of different toolchains,
(eg a Windows CE port of GRUB, or a Windows (ME) port of grub-setup) I
still recommend running configure multiple times.


> 
> Can you please make a changelog entry for this patch?

Will do.

> > +if test "x$host_cpu" = xarm; then
> > +  AC_PATH_PROG(PERL, perl)
> > +fi
> > +
> 
> Why do you need perl?

A perl program is used to convert the list of machine names 
and numbers from Linux.


> > +    GRUB_ERR_FILE_CLOSE_ERROR,
> > +    GRUB_ERR_FILE_OPEN_ERROR,
> > +    GRUB_ERR_DIR_READ_ERROR
> 
> When are these errors triggered, btw?

When the corresponding RISC OS system call returns an error.

> Can't you use GRUB_ERR_BAD_FS 
> or GRUB_FS_BAD_FILE_TYPE instead?

The error is probably not one of those, and could almost anything.


 
> > +void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
> > +void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
> 
> Why do you want to do this?  Can't you just use grub_memcpy and
> grub_memset instead?

They are called implictally by gcc.

> > -#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), @function ; EXT_C(x):
> > -#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), @object ; EXT_C(x):
> > +#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), "function" ; EXT_C(x):
> > +#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), "object" ; EXT_C(x):
> 
> Can you please explain this change?

"@" marks the start of a comment in ARM GNU as syntax, producing a syntax
error. I expect double quotes to work for all architures. Tested on x86 and PowerPC.

> >  }
> > +
> >  void *memmove (void *dest, const void *src, grub_size_t n)
> >    __attribute__ ((alias ("grub_memmove")));
> > +
> 
> Please watch out with adding white lines.

IMO, there should be white space there to make it more readable.

> Does GRUB 2 still work on the PC after this patch is committed?

Yes
> 
> Thanks,
> Marco
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 

-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

Whoops, I just noticed I forgot to answer this email... :/

>> > Define BUILD to "build/" when cross compiling or to ""
>> > when not cross-compiling and prefix use of the utilites
>> > in makefiles with $(BUILD).
>> >
>> > Shall I do that?
>> 
>> This does not look like a clean solution to me.
>
>> Normally this is not 
>> required to do it like this, right?
>
> The gcc package also uses multiple runs of configure.
>
> You're right, genmoddep does not require the services of configure,
> but then why was support for checking the build system compiler
> added to configure.ac?
>
> I suggest removing that support, and only use BUILD_CC for compiling
> genmoddep. Support for building cross versions of the tools could be
> retained by supporting configure's --target option. 

So you mean you can choose if grub-mkimage is compiled for the host or
target system?  I think that would be useful.  Considering two
scenarios:

1) Building the PPC version of GRUB using a PC.  In the case
   grub-mkimage (the one form the ieee1275/ppc directory) works on the
   PC, I can make an ELF including some modules.  This is really
   useful when developing.

2) When cross-compiling a Debian package, everything has to be build
   for the host, with some specific tools used in the buildprocess as
   an exception.

So if configure somehow supports this in a sane way, it would seem
nice to have.  As most people here know, I am quite clueless about the
autotools... :/

>> Why do you need perl?
>
> A perl program is used to convert the list of machine names 
> and numbers from Linux.

I have my doubts about adding a dependency for perl to GRUB, although
it is required for automake too.  So when is it required, when the
developers change something or when a user wants to compile it?

>> Can't you use GRUB_ERR_BAD_FS 
>> or GRUB_FS_BAD_FILE_TYPE instead?
>
> The error is probably not one of those, and could almost anything.

Sorry, I do not understand what you mean.

>
>  
>> > +void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
>> > +void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
>> 
>> Why do you want to do this?  Can't you just use grub_memcpy and
>> grub_memset instead?
>
> They are called implictally by gcc.

Right.  I had stuff like this in the PPC port as well.  Perhaps you
can make a libgcc.h, like I did for the PPC port?

>> > -#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), @function ; EXT_C(x):
>> > -#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), @object ; EXT_C(x):
>> > +#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), "function" ; EXT_C(x):
>> > +#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), "object" ; EXT_C(x):
>> 
>> Can you please explain this change?
>
> "@" marks the start of a comment in ARM GNU as syntax, producing a syntax
> error. I expect double quotes to work for all architures. Tested on x86 and PowerPC.

Ok.

Thanks,
Marco

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

> Instead part of functionality of the stubs is included in 
> kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
> for them. For clairity I suggest we use the standard names, as opposed to 
> prefixing the names with grub_RISC_OS_ or simular.

Better use a prefix, right?  I don't see how it will get clearer by
not using the prefix.  And the coding style used in GRUB says to use
prefixes, so we can better do that unless it really is not possible.

Thanks,
Marco

Re: RISC OS port

[Johan Rydberg]

Marco Gerards <metgerards@student.han.nl> writes:

> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
>
>> Instead part of functionality of the stubs is included in 
>> kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
>> for them. For clairity I suggest we use the standard names, as opposed to 
>> prefixing the names with grub_RISC_OS_ or simular.
>
> Better use a prefix, right?  I don't see how it will get clearer by
> not using the prefix.  And the coding style used in GRUB says to use
> prefixes, so we can better do that unless it really is not possible.

And please choose something else than grub_RISC_OS_ -- like
grub_risc_os.  Otherwise I will not be able to get a good nights sleep
for years to come.


~j

Re: RISC OS port

[Timothy Baldwin]

On Friday 03 Dec 2004 12:53, Marco Gerards wrote:
> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
> 
> > Instead part of functionality of the stubs is included in 
> > kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
> > for them. For clairity I suggest we use the standard names, as opposed to 
> > prefixing the names with grub_RISC_OS_ or simular.
> 
> Better use a prefix, right?  I don't see how it will get clearer by
> not using the prefix.

Using a prefix would suggest that the function was defined in
GRUB. Without the prefix the function is instantly recognisable
as a system C library function.

For example: What does grub_risc_os_system do?

Using standard names for externally defined functions is established
practise in GRUB, but previousally we have not had the choice.

> And the coding style used in GRUB says to use 
> prefixes, so we can better do that unless it really is not possible.

It isn't set in stone.
-- 
Member AFFS, WYLUG, SWP (UK), ANL, RESPECT, Leeds SA, Leeds Anti-war coalition
No to software patents!    Victory to the iraqi resistance!

Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

> On Friday 03 Dec 2004 12:53, Marco Gerards wrote:
>> Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:
>> 
>> > Instead part of functionality of the stubs is included in 
>> > kern/arm/RISC_OS/startup.S, as such we are free to choose which names we use 
>> > for them. For clairity I suggest we use the standard names, as opposed to 
>> > prefixing the names with grub_RISC_OS_ or simular.
>> 
>> Better use a prefix, right?  I don't see how it will get clearer by
>> not using the prefix.
>
> Using a prefix would suggest that the function was defined in
> GRUB. Without the prefix the function is instantly recognisable
> as a system C library function.

I do not agree.  The different names are used so the namespace is not
messed up easily.  Especially for functions like strcmp, etc that is
important.

> Using standard names for externally defined functions is established
> practise in GRUB, but previousally we have not had the choice.

You are wrong.  Just have a look at the functions with the
"grub_ieee1275_" prefix.  Those functions are calls into the ieee1275
firmware.

>> And the coding style used in GRUB says to use 
>> prefixes, so we can better do that unless it really is not possible.
>
> It isn't set in stone.

It should be IMHO.  GRUB would become a mess if there was not a single
coding style.

Thanks,
Marco