From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: RISC OS port
Date: Fri, 26 Nov 2004 10:18:29 +0000 [thread overview]
Message-ID: <87sm6wrk0a.fsf@marco.marco-g.com> (raw)
In-Reply-To: <200411260047.59184.T.E.Baldwin99@members.leeds.ac.uk> (Timothy Baldwin's message of "Fri, 26 Nov 2004 00:47:45 +0000")
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
next prev parent reply other threads:[~2004-11-26 10:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-23 17:00 RISC OS port Timothy Baldwin
2004-11-23 18:03 ` Marco Gerards
2004-11-26 0:47 ` Timothy Baldwin
2004-11-26 10:18 ` Marco Gerards [this message]
2004-11-26 12:57 ` Yoshinori K. Okuji
2004-11-27 1:36 ` Timothy Baldwin
2004-11-27 18:21 ` Timothy Baldwin
2004-12-03 13:07 ` Marco Gerards
2004-12-04 10:30 ` Timothy Baldwin
2004-12-29 19:46 ` Marco Gerards
2004-12-03 12:53 ` Marco Gerards
2004-12-03 13:51 ` Johan Rydberg
2004-12-04 10:27 ` Timothy Baldwin
2004-12-04 13:14 ` Marco Gerards
-- strict thread matches above, loose matches on Subject: below --
2013-05-03 11:49 Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sm6wrk0a.fsf@marco.marco-g.com \
--to=metgerards@student.han.nl \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.