Re: RISC OS port

[Marco Gerards]

Timothy Baldwin <address@hidden> writes:

> On Tuesday 23 Nov 2004 18:03, Marco Gerards wrote:
>> Timothy Baldwin <address@hidden> 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