Re: Determining boot server and own IP on sparc64-ieee1275

[David Miller]

From: Vladimir 'φ-coder/phcoder' Serbinenko 
Date: Wed, 06 Jul 2011 14:13:20 +0200

> 1) Is there any way to retrieve client and server IP on sparc64 used by
> IEEE1275 or do we have to redo RARP ourselves?

"/chosen/{client,server,gateway}-ip"

> According to a web search newer sparc machines use BOOTP or DHCP instead
> of or as an alternative to RARP.

I am not familiar with anything in sparc openboots that supports full
blown DHCP, sorry.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Fallback to scanning OF tree if no devaliases

[David Miller]

From: lsore...@csclub.uwaterloo.ca (Lennart Sorensen)
Date: Thu, 29 Jul 2010 12:59:08 -0400

> On Thu, Jul 29, 2010 at 09:52:18AM -0700, David Miller wrote:
>> From: Doug Nazar 
>> Date: Thu, 29 Jul 2010 11:57:50 -0400
>> 
>> > How common is it not to have nvalias's? Is that usual operating
>> > procedure?
>> 
>> FWIW, I've never seen this on a sparc64 system, ever.
> 
> So the sparc does not have devaliases by default and people don't
> normally use them, or the sparc (like the powermac) automatically
> creates useful devalises?

Sparc64 always has useful aliases.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Fallback to scanning OF tree if no devaliases

[David Miller]

From: Doug Nazar 
Date: Thu, 29 Jul 2010 11:57:50 -0400

> How common is it not to have nvalias's? Is that usual operating
> procedure?

FWIW, I've never seen this on a sparc64 system, ever.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GIT mirror of BZR repo

[David Miller]

From: "KESHAV P.R." 
Date: Thu, 11 Mar 2010 21:20:42 +0530

> If u guys have any plans for a git repo (or mirror) , I will be glad
> to change over to it.

Yes, please provide an uptodate GIT mirrot of the grub
sources.

I've simply stopped trying to work on grub after the
transition to bzr, using it is just too painful.

Mandating bzr for the master repository is fine, but
not providing alternatives for people who just want
to keep up with the tree is not.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Dynamic device.map

[David Miller]

From: Robert Millan 
Date: Sat, 26 Dec 2009 14:25:51 +0100

> Then we rely only on UUIDs.

This is exactly what I suggested we should avoid.

On OpenFirmware we scan every device alias, %80 of them point to
non-existing devices.  The aliases are just an enumeration of
the set of devices that could be behind a controller, not what
has actually been detected by the firmware or anything like
that.

So every scan for a UUID can eat up an enormous amount of time,
poking devices that simply are not there.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Don't open same disk twice on OpenFirmware.

[David Miller]

From: David Miller 
Date: Fri, 18 Dec 2009 10:33:13 -0800 (PST)

> From: Vladimir 'φ-coder/phcoder' Serbinenko 
> Date: Fri, 18 Dec 2009 17:17:13 +0100
> 
>> Hello, all. According to David Miller sparc's openboot doesn't support
>> opening same disk twice. So I implemented handle reusage logic. Tested
>> on imac g3
> 
> At a minimum you have to seek to the beginning of the device
> as that is one of the many side effects of openning the
> device.

In fact this proves that your idea can't ever work.
Each openned instance will expect the file offset
pointer to be at different locations.

You can't share open instances, therefore.

We really just have to make sure GRUB never violates
this restriction.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Don't open same disk twice on OpenFirmware.

[David Miller]

From: Vladimir 'φ-coder/phcoder' Serbinenko 
Date: Fri, 18 Dec 2009 17:17:13 +0100

> Hello, all. According to David Miller sparc's openboot doesn't support
> opening same disk twice. So I implemented handle reusage logic. Tested
> on imac g3

At a minimum you have to seek to the beginning of the device
as that is one of the many side effects of openning the
device.

I really don't think this is a good idea, really.

We sould just enforce the restriction, and put a debugging
check there to make sure the invariant is never violated.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Robert Millan 
Date: Mon, 7 Dec 2009 15:04:11 +0100

> On Sun, Dec 06, 2009 at 04:21:50PM -0800, David Miller wrote:
>> From: Robert Millan 
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>> 
>> > We're actually in the process of getting rid of device.map;
>> 
>> Meanwhile, please fix the regression you added to the tree. :-)
> 
> I think this should do it.  Please can you test?

This patch works fine for me, thanks!


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mkrelpath doesn't do what it should...

[David Miller]

From: Felix Zielcke 
Date: Mon, 07 Dec 2009 11:39:22 +0100

> The one mount point case is now fixed in r1917
> See Subject: `handling mount points in grub-mkrelpath' from me for the
> patch.

Seems to work properly now.  The paths all start with "//" but
I guess that's ok.

Thanks!


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mkrelpath doesn't do what it should...

[David Miller]

From: Felix Zielcke 
Date: Mon, 07 Dec 2009 23:06:46 +0100

> Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller:
>> In fact I don't see why these scripts don't do that, and relatively
>> resolve the /boot directory whatever seperately. 
> 
> Because it's faster to just call once for the directory
> make_system_path_relative_to_its_root() instead of once for every kernel
> you have.
> Colin even added caching for prepare_grub_to_access_device() because it
> can be slow if you have many many kernels.

Ok, makes sense, thanks for explaining.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Robert Millan 
Date: Mon, 7 Dec 2009 15:05:16 +0100

> On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
>> From: Robert Millan 
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>> 
>> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
>> > of hardcoding, etc.
>> 
>> Well, for one thing I don't use initrd's for my Linux kernels,
>> therefore specifying root devices via UUIDs isn't going to work.
> 
> I was referring to use of UUIDs internally by GRUB (e.g. the search command
> instances grub-mkconfig generates).

Ok, but as noted in another thread this can make grub
very slow on ieee1275 systems as we are going to look
for the UUID on every ieee1275 device alias present and
there can be tons of those.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Mon, 07 Dec 2009 12:52:01 +0100

> It already works on MIPS and AFAICT only thing it needs to work is PCI.
> Do you mean that accessing PCI on sparc is a lot of work?

Even just calculating the register addresses is a lot of work.

You can't just take the property values for the device as-is, you have
to walk up to the root applying 'range' property translations to the
register addresses.

And there are special cases and quirks all over the place.

The code to do this in the Linux kernel is several thousand lines of
code.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mkrelpath doesn't do what it should...

[David Miller]

From: Felix Zielcke 
Date: Mon, 07 Dec 2009 11:39:22 +0100

> Am Sonntag, den 06.12.2009, 23:30 -0800 schrieb David Miller:
>> I was trying to figure out why the kernel image paths generated
>> automatically for me by grub-mkconfig were not correct.
>> 
>> I have /boot on a seperate partition, but in the generated config
>> files it uses paths like /boot/vmlinux-2632 etc.
>> 
>> The problem is grub-mkrelpath and it's usage in the scrips such as
>> "10_linux".
>> 
>> "/boot" is given to "grub-mkrelpath", and this results in
>> the identical "/boot" in rel_dirname.
>> 
>> So all the paths emitted by 10_linux end up being "/boot" based
>> instead of "/" based.
>> 
>> grub-mkrelpath seems to do the right thing if I pass it a full path,
>> f.e. giving it "/boot/vmlinux" emits the correct "/vmlinux"
> 
> The one mount point case is now fixed in r1917
> See Subject: `handling mount points in grub-mkrelpath' from me for the
> patch.

Thanks I'll have a look.

Locally for testing, I changed the 10_linux script to pass the
complete image path name to the device root relative pathname
resolver.  That worked just as well.

In fact I don't see why these scripts don't do that, and relatively
resolve the /boot directory whatever seperately.



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Mon, 07 Dec 2009 12:05:24 +0100

> Committed.
> David Miller wrote:
>> I tried to surmise other ways to do this more cleanly, such as
>> resolving the path and looking for some device property inside of the
>> resulting node, but there simply isn't anything we can check for.
>>
>>   
> If you find a cleaner way we can commit it later. I was thinking of
> resolving path to hardware one and then querying hardware directly but
> it may conflict with OF. What do you think?

I don't think that is wise.

We would then need two mappings, OF --> OS and OS --> OF for
device naming.  And all of that complexity for what?  This
silly cdrom issue where a simple strncmp() is solving the
problem quite well so far?

There are conventions for alias names created by default by
the firmware, so we should be OK with the patch I have written
here.

> How much work would be needed to make ata.mod work on sparc64?

Probably a lot.

> Which other drivers we would need to reasonably replace ofdisk (which
> would still be available as fallback)?

I don't think it's worthwhile to break away from ofdisk, it works
quite well.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Mon, 07 Dec 2009 11:48:07 +0100

> The problem actually is the following:
> When we're in OS we know the OS device name but not the firmware device
> name. So we're able to generate correct root= for kernel command line
> but can only guess which names you would need for grub's set root=. The
> solution we're going for is to have UUID of fs stored in grub.cfg and go
> through all partitions on boot and find the right one nd set it to root
> variable. As for passing root= kernel parameter the decision of using
> device name or UUID= is based on heuristics (sigh) but you can disable
> them altogether in /etc/default/grub:
> 
> # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
> Linux
> #GRUB_DISABLE_LINUX_UUID=true

UUIDs are convenient but can be very time consuming.

Some sparc64 systems come with 10 or 20 block OpenFirmware device
aliases, and we're going probe all of them, one by one, to look for
the UUID.

The firmware device name is so trivially obtainable, especially on
ieee1275.  That's what the grub-ofpathname tool I wrote does on
sparc64.  And it's what the 'ofpathname' script used by powerpc on
grub does as well.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Colin Watson 
Date: Mon, 7 Dec 2009 10:20:16 +

> On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
>> From: Robert Millan 
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>> 
>> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
>> > of hardcoding, etc.
>> 
>> Well, for one thing I don't use initrd's for my Linux kernels,
>> therefore specifying root devices via UUIDs isn't going to work.
> 
> Then don't use that feature of grub-mkconfig (i.e. set
> GRUB_DISABLE_LINUX_UUID=false in /etc/default/grub). That's independent
> of device.map handling, though.

grub-mkconfig actually seems to do this automatically for me.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

mkrelpath doesn't do what it should...

[David Miller]

I was trying to figure out why the kernel image paths generated
automatically for me by grub-mkconfig were not correct.

I have /boot on a seperate partition, but in the generated config
files it uses paths like /boot/vmlinux-2632 etc.

The problem is grub-mkrelpath and it's usage in the scrips such as
"10_linux".

"/boot" is given to "grub-mkrelpath", and this results in
the identical "/boot" in rel_dirname.

So all the paths emitted by 10_linux end up being "/boot" based
instead of "/" based.

grub-mkrelpath seems to do the right thing if I pass it a full path,
f.e. giving it "/boot/vmlinux" emits the correct "/vmlinux"

Casually inspecting make_system_path_relative_to_its_root() shows what
appears to be another bug.  It seems to immediately break from the
loop when a different device number than "/"'s is seen, but what if I
have:

/one/two/three

Where / is /dev/hda1, /one/two is /dev/hda2 and /one/two/three is yet
another mount from /dev/hda3.  It seems like the premature loop exit
in this function will give us the wrong result here.

The loop needs to remember the string prefix point at which every
device number change occurs, and once the whole path has been
traversed it should unwind back to that point in order to emit
the result.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

We skip CDROMs in the block device iterator because they simply can't
be openned safely unless we absolutely know there is a CDROM drive
there and there is in fact a disc in the drive.

Openning it blindly results in either a 10 second hang during the open
call, or even worse a crash in OpenFirmware.

My SunBlade100 wouldn't boot a kernel properly because not only does
it by default have a "cdrom" alias, it also has two others named
"cdrom1" and "cdrom2".

So to cover all cases, match "cdrom" as a 5 character prefix of the
alias name in the check.

I tried to surmise other ways to do this more cleanly, such as
resolving the path and looking for some device property inside of the
resulting node, but there simply isn't anything we can check for.

BTW, if people want to look at some OpenFirmware device tree dumps on
just about every sparc64 system type there is a GIT repo where we
maintain such things contributed by various sparc64 Linux users at:

git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git

There are some 32-bit sparc dumps in there, but the majority are
64-bit systems.

Anyways, here is the fix, please apply thanks!

2009-12-06  David S. Miller  

* disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Recognize
anything even prefixed with 'cdrom' as a cdrom.

=== modified file 'disk/ieee1275/ofdisk.c'
--- disk/ieee1275/ofdisk.c  2009-06-10 21:04:23 +
+++ disk/ieee1275/ofdisk.c  2009-12-07 02:13:52 +
@@ -107,7 +107,7 @@
}
 
   if (! grub_strcmp (alias->type, "block") &&
- grub_strcmp (alias->name, "cdrom"))
+ grub_strncmp (alias->name, "cdrom", 5))
ret = hook (alias->name);
   return ret;
 }



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Robert Millan 
Date: Sun, 6 Dec 2009 14:10:26 +0100

> grub-mkconfig generates a grub.cfg that relies on UUIDs instead
> of hardcoding, etc.

Well, for one thing I don't use initrd's for my Linux kernels,
therefore specifying root devices via UUIDs isn't going to work.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Broken common.rmk change

[David Miller]

From: Robert Millan 
Date: Sun, 6 Dec 2009 14:10:26 +0100

> We're actually in the process of getting rid of device.map;

Meanwhile, please fix the regression you added to the tree. :-)

And I'll look into what you've mentioned to see if that kind of scheme
will work properly on Sparc.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Broken common.rmk change

[David Miller]

Robert, the set of objects used to build grub-mkdevicemap on
sparc64-ieee1275 is not the same as those used on other architectures.
So this change was not correct:

2009-11-26  Robert Millan  

* conf/common.rmk (sbin_UTILITIES): Add `grub-mkdevicemap'.
 ...
* conf/i386-coreboot.rmk (sbin_UTILITIES): Remove `grub-mkdevicemap'.
(grub_mkdevicemap_SOURCES): Remove.
 ...
* conf/sparc64-ieee1275.rmk: Likewise.

In particular, we use a special implementation devicemap.c on
sparc64-ieee1275 so that openfirmware device nodes are emitted instead
of "hd0" et al.

So when you moved the build rule into common.rmk you broke this.

This is probably the primary reason that the current tree works for
nobody on sparc64 :-)

Before I found this problem, I tested with an existing devicemap and
config file on a Niagara LDOM Linux guest and current trunk worked as
well as it did when I was last active several months ago and I was
able to boot Linux kernels with it.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Robert Millan 
Date: Fri, 4 Dec 2009 21:58:25 +0100

> On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote:
>> 
>> Thanks, but I don't feel comfortable enough with bzr yet.
>> 
>> I had to struggle just to get things checked out, as the bzr
>> package in Debian stable is too old to use to access to repo.
>> 
>> (For the record I disagree with the source control system choosen,
>>  and the fact that a common current Linux distribution doesn't even
>>  provide a version of the tool necessary to access the repo really
>>  convinces me further of that.)
> 
> For a Lenny system the following should do the trick:
> 
>   echo "deb http://backports.org/debian lenny-backports main" | sudo tee -a 
> /etc/apt/sources.list
>   gpg --keyserver pgp.mit.edu --recv-keys 16BA136C
>   gpg --export -a 16BA136C | sudo apt-key add -
>   sudo apt-get update
>   sudo apt-get install -t lenny-backports bzr

That's not a straightforward and low barrier of entry for new
developers who want to simply check out the grub code and start
contributing.  That's my point.

Do you want lots of people involved, or do you want people to have
to jump through hoops and go out of their way to get at your tree?

Heck, for this reason alone, subversion was a better situation.

Mercurial, GIT, or pretty any other distributed source control system
would have worked out of the box with the client versions provided in
debian stable and other distributions.

So, I still believe BZR was a bad choice of a source control system.

And how many times have you guys wrecked your repository already?
:-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Thu, 03 Dec 2009 22:56:34 +0100

> The problem is that nobody of us has such hardware. I would happily do a
> sparc boot every 2 weeks but I just don't have a sparc

You can get an Ultra5 for ~$100.00 USD on EBAY :-)

Anyways, no matter, I'm about to start working to get grub2
functional again at least on a few of my machines.

Thanks!


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Thu, 03 Dec 2009 21:22:27 +0100

> David Miller wrote:
>>> Committed.
>>> 
>>
>> Thanks.
>>
>>   
> You can commit to bzr yourself actually. And unless Robert objects I
> guess your permission to tangle with sparc parts as you see fit is still
> valid

Thanks, but I don't feel comfortable enough with bzr yet.

I had to struggle just to get things checked out, as the bzr
package in Debian stable is too old to use to access to repo.

(For the record I disagree with the source control system choosen,
 and the fact that a common current Linux distribution doesn't even
 provide a version of the tool necessary to access the repo really
 convinces me further of that.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Thu, 03 Dec 2009 21:22:27 +0100

> For me the main reason for or against it is break probability. Merging
> will avoid stupid breakages like ones you fixed but may introduce more
> subtle ones

You lack a cross-build environment?

I test build the Linux kernel for about 4 or 5 platforms, all on the
same computer.

And also as we've seen, keeping the build working doesn't keep bugs
from creeping in.  Someone just needs to actively build and install
test the tree on the given platform if you really want to avoid
problems.

I have about half a year of potential regressions I'm about to
discover on sparc64.  That's not an acceptable situation, long term.

I might get hit by a bus or whatever, so it would be nice if someone
other than me were at least testing the code base out on sparc64.

That way problems get spotted when they get added, or soon afterwards,
not 6 months later like some things are about to. :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '$B&U(B-coder/phcoder' Serbinenko 
Date: Thu, 03 Dec 2009 12:26:05 +0100

> Hello, nice to see you again.
> David Miller wrote:
>> So I finally am about to have enough time to start looking into
>> sparc64 support again.
>>
>>   
> 
>> And, surprise!  The trunk doesn't even build. :-)
>>   
> Committed.

Thanks.

> BTW in experimental we merged sparc64's and i386's grub-install. Do
> you think it would make sense to merge some other tools as well?

Maybe.  I made a lot of changes when I cribbed the i386 versions,
and made some cleanups as well, but some portions should be sharable.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix sparc64 build...

[David Miller]

So I finally am about to have enough time to start looking into
sparc64 support again.

And, surprise!  The trunk doesn't even build. :-)

2009-12-03  David S. Miller  

* conf/sparc64-ieee1275.rmk (grub_mkimage_SOURCES,
grub_setup_SOURCES, grub_ofpathname_SOURCES): Add gnulib/progname.c
* util/sparc64/ieee1275/grub-mkimage.c: Include  and
"progname.h"
* util/sparc64/ieee1275/grub-ofpathname.c: Likewise.
* util/sparc64/ieee1275/grub-setup.c: Likewise.
(usage): Add missing comma in printf.

=== modified file 'conf/sparc64-ieee1275.rmk'
--- conf/sparc64-ieee1275.rmk   2009-11-26 00:45:53 +
+++ conf/sparc64-ieee1275.rmk   2009-12-03 10:06:44 +
@@ -63,7 +63,7 @@
 
 # For grub-mkimage.
 grub_mkimage_SOURCES = util/sparc64/ieee1275/grub-mkimage.c util/misc.c \
-util/resolve.c
+util/resolve.c gnulib/progname.c
 
 # For grub-setup.
 util/sparc64/ieee1275/grub-setup.c_DEPENDENCIES = grub_setup_init.h
@@ -82,12 +82,12 @@
partmap/sun.c partmap/acorn.c   \
\
disk/raid.c disk/mdraid_linux.c disk/lvm.c  \
-   util/raid.c util/lvm.c  \
+   util/raid.c util/lvm.c gnulib/progname.c\
grub_setup_init.c
 
 # For grub-ofpathname.
 grub_ofpathname_SOURCES = util/sparc64/ieee1275/grub-ofpathname.c \
-   util/ieee1275/ofpath.c util/misc.c
+   util/ieee1275/ofpath.c util/misc.c gnulib/progname.c
 
 # Scripts.
 sbin_SCRIPTS = grub-install

=== modified file 'util/sparc64/ieee1275/grub-mkimage.c'
--- util/sparc64/ieee1275/grub-mkimage.c2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-mkimage.c2009-12-03 09:59:51 +
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,8 @@
 #define _GNU_SOURCE1
 #include 
 
+#include "progname.h"
+
 static void
 compress_kernel (char *kernel_img, size_t kernel_size,
 char **core_img, size_t *core_size)

=== modified file 'util/sparc64/ieee1275/grub-ofpathname.c'
--- util/sparc64/ieee1275/grub-ofpathname.c 2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-ofpathname.c 2009-12-03 10:06:14 +
@@ -20,6 +20,10 @@
 #include 
 #include 
 
+#include 
+
+#include "progname.h"
+
 int main(int argc, char **argv)
 {
   char *of_path;

=== modified file 'util/sparc64/ieee1275/grub-setup.c'
--- util/sparc64/ieee1275/grub-setup.c  2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-setup.c  2009-12-03 10:04:44 +
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,6 +50,8 @@
 #define _GNU_SOURCE1
 #include 
 
+#include "progname.h"
+
 /* This program fills in various fields inside of the 'boot' and 'core'
  * image files.
  *
@@ -419,7 +422,7 @@
   -v, --verbose   print verbose messages\n\
 \n\
 Report bugs to <%s>.\n\
-", program_name
+", program_name,
DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY,
DEFAULT_DEVICE_MAP, PACKAGE_BUGREPORT);
 



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke 
Date: Wed, 28 Oct 2009 11:24:58 +0100

> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>> David are you still there?
>> And also anyone who has access to a powerpc machine (and experience)?
>> 
>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
> 
> Ok the internal gcc symbols for sparc have been fixed now.
> But now there's another problem on sparc:
> 
>   ok boot
>   Boot device: disk  File and args: 
>   GRUB Illegal Instruction
>   ok 

Like I said, I won't be able to look into these kinds of things
for at least a month or so and I doubt anyone else here has the
sparc knowledge necessary to help you diagnose this.

Sorry.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Pavel Roskin 
Date: Thu, 15 Oct 2009 18:41:41 -0400

> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
> on Sparc64, even if those functions are present and even if
> --disable-werror is used.

They worked perfectly fine for me on a real system with
a real compiler and glibc.

If you're going to use cross compilation to test, use
a full cross toolset and glibc build not some hacked
up uclibc thing.

I also believe that even if it still fails for you,
native building is more important to work than cross
building situations.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko 
Date: Mon, 12 Oct 2009 17:45:33 +0200

> Another idea: we could use nm to generate list of functions in libgcc.

Yes, 'nm' would work too.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Bean 
Date: Mon, 12 Oct 2009 18:31:12 +0800

> To use the libgcc, we need to link the object file, this doesn't work
> in system that use non ELF format like mach-o.

How can one even build programs in the mach-o format if linking
object files is not allowed? :-)

If this is just for embedded cross compile situations, just forget it.

We just require that you have a fully functioning cross build
environment and that means you need to have a C library around.



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko 
Date: Mon, 12 Oct 2009 12:26:04 +0200

> It was removed as a part of following commit
> 2009-06-10  Pavel Roskin  
> 
> * configure.ac: Use -nostdlib when probing for the target.  It
> should not be required to have libc for the target.
> 
> * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
> they fail without libc headers for the target.
> * include/grub/powerpc/libgcc.h: Use weak attribute for all
> exports.
> * include/grub/sparc64/libgcc.h: Likewise.  Don't use
> preprocessor conditionals.
> 
> Do you think we should just revert it?

Probably.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Bean 
Date: Mon, 12 Oct 2009 17:58:42 +0800

> Try my branch, it includes the libgcc functions in grub instead of
> rely on external library. It builds and run properly for
> powerpc-ieee1275 last time I check.

Good luck when the compiler changes the interface and/or semantics of
these routines in a future version.  Will you enumerate your in-tree
copies by gcc version with ifdefs or similar?

That's why gcc and it's libgcc are distributed together, and gcc
configures itself to link with a specific libgcc and only that libgcc.

This whole things perfectly fine in GRUB when I implemented the
necessary machinery to find if these routines exist in libgcc at
configure time and to reference them properly in the build.

They've merely been broken meanwhile and someone just needs to rectify
that regression.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko 
Date: Mon, 12 Oct 2009 11:56:23 +0200

> How accurate is qemu-system-sparc64? We could have an automated
> regression testing for it - this should keep grub-sparc reasonably
> working and permit minor (and perhaps even major) developpement

Personally, I don't know as I've never used it.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke 
Date: Mon, 12 Oct 2009 10:55:46 +0200

> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030

I'm about to head to Tokyo for the Linux Kernel summit and
the Japan Linux Symposium so I'll be out of commission for
a few weeks again.

Right when I'm about to get back to even trying out the latest
GRUB I hit another conference or major trip.

So please do not make me the critical link in the chain for Sparc
things until later this year.  If these things are to be fixed sooner
than that, someone else will need to look into them.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Require at least gcc 4.2

[David Miller]

From: Robert Millan 
Date: Sat, 5 Sep 2009 23:26:11 +0200

> David et al, can we agree on a minimal version of GCC that we should
> recommend?
> 
> For mentioning in the INSTALL file only.  I assume nobody's interested in
> gcc 2.95.

I think gcc-4.1.x, maybe specifically gcc-4.1.3 is a reasonable
base point.

If we want to go back as far as gcc-3.4.x, probably gcc-3.4.6


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[David Miller]

From: "Vladimir 'phcoder' Serbinenko" 
Date: Thu, 3 Sep 2009 17:08:34 +0200

> I can't agree with designating nested functions as root issue. Imagine
> tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
> reason to replace all "for"s with "while"s. The root issue is compiler
> bug and it should be fixed

I can tell you that in kernel land when we encounter a compiler
bug we usually have to simply cope with it somehow, and if that
means rearranging some loop to not trigger a bug that is sometimes
what it indeed does mean.

Also, a small project using a pretty obscure feature of gcc was in a
way asking for trouble :-)

But if you want to decrease your testing base every time we hit some
compiler bug you don't particularly like, well I guess that's your
perogative then...


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[David Miller]

From: Yves Blusseau 
Date: Tue, 1 Sep 2009 21:30:01 +0200

> 
> Le 1 sept. 09 à 17:43, Bean a écrit :
> 
>> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
>> properly by removing nested function, this also has other advantages,
>> like allowing to run tools on systems like OSX that doesn't allow to
>> execute code in stack by default.
> 
> Agree with Bean, it's the last "issue" that made that we can't run
> tool on OSX directly.

I agree too, fixing the root issue would be a much better
cure for this rather than alienating everyone who happens
to be using older tools on their computer.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Require at least gcc 4.2

[David Miller]

From: "Vladimir 'phcoder' Serbinenko" 
Date: Tue, 1 Sep 2009 19:02:39 +0200

> Even if it's not so I still think dropping support for old building
> environments is a good thing since it decreases bug possibilities
> and so maintainance work too.

It also decreases your testing base.

I think this change is short-sighted.

If anything, only make this restriction on x86 platforms,
which is the only place where this issue even happens.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Require at least gcc 4.2

[David Miller]

From: "Vladimir 'phcoder' Serbinenko" 
Date: Tue, 1 Sep 2009 16:12:20 +0200

> Even if gcc<4.2 seem to work ok I think we shouldn't waste resources
> on it and officially declare a minimal requirement ("you're free to go
> under requirement but don't post bugreports if you do")

You're making it such that I won't be able to do development on my
main sparc development machine, which is using gcc-4.1.3

In my view, this is going a bit overboard as a method to address this
problem.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: sparc: [Fwd: Bug#538030: grub-ieee1275 fails to install bootblock]

[David Miller]

From: Felix Zielcke 
Date: Wed, 22 Jul 2009 20:11:44 +0200

> Just mail him: Alexander Vlasov 
> but then please also CC the bug report: 538...@bugs.debian.org
> You could ask then also if he wants to subscribe to grub-devel but if
> not then please CC him + the bug report for everything which is
> relevant.

OK.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: sparc: [Fwd: Bug#538030: grub-ieee1275 fails to install bootblock]

[David Miller]

From: Robert Millan 
Date: Wed, 22 Jul 2009 19:57:49 +0200

> On Wed, Jul 22, 2009 at 05:45:41PM +0200, Felix Zielcke wrote:
>> > grub-mkdevicemap: error: Cannot open SAS PHY ID 
>> > '/sys/devices/root/f0063e50/pci:02/:02:00.0/:03:09.0/:0a:00.0/:0b:01.0/host0/port-0:0/end_device-0:0/sas_device:end_device-0:0/phy_identifier'
>> > ---
> 
> I think we should make GRUB tollerant to broken device.map on sparc, like
> we did for i386-pc.  But I'm not sure if this is possible.

I'll look into this when I can next month.

But for the initial bug this user has, can we find out what lives
inside of this directory:

/sys/devices/root/f0063e50/pci:02/:02:00.0/:03:09.0/:0a:00.0/:0b:01.0/host0/port-0:0/end_device-0:0/sas_device:end_device-0:0/

and if that directory doesn't exit, can they go back one directory node
at a time until something appears?


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: sparc: [Fwd: Bug#538030: grub-ieee1275 fails to install bootblock]

[David Miller]

From: Felix Zielcke 
Date: Wed, 22 Jul 2009 17:45:41 +0200

> could you please have a look at this?
> It's a sparc problem.

I won't even be close to being able to look into this until
late August as I'm currently in New York City and therefore
thousands of miles from my Sparc systems :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: OLPC regression, ofdisk stops working

[David Miller]

From: Robert Millan 
Date: Fri, 10 Jul 2009 19:41:15 +0200

> On Fri, Jul 10, 2009 at 10:28:03PM +0800, Bean wrote:
>> Hi,
>> 
>> There is something wrong with r2132, now childtype is a pointer, so
>> sizeof childtype == 4, the name would be truncated to 4 characters.
> 
> Bean, you never cease to amaze me.  I admit the "interesting, exactly
> the word size" idea crossed my head, but I didn't reach any conclussion
> out of it :-)
> 
> Nice catch.  Will you commit this, or want me to?

Good catch, I thought I had gotten all of those size
conversions correct, guess not :-/



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Data loss at savannah.gnu.org

[David Miller]

From: Felix Zielcke 
Date: Tue, 02 Jun 2009 23:12:15 +0200

> Okuji already said once [0] that he could add a new co-maintainer.
> The only reply was from Robert [1] that he doestn't have time.
> I wonder why I didn't reply. Well anyway I would have time but I don't
> think I would be a good GNU maintainer, especially for reviewing other
> patches. Ugh.

Personally, I would be more than happy to see you in this role.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Data loss at savannah.gnu.org

[David Miller]

From: Marco Gerards 
Date: Tue, 02 Jun 2009 17:17:46 +0200

> No offense, but didn't Okuji implement more than most of us did?  He
> actually wrote all the intial code of GRUB 2 from scratch.

RMS did the same for GCC, but now he concentrates his efforts
on other activities and doesn't pretend to be the GCC maintainer.

> Besides that, a maintainer has to take care that the project remains a
> true GNU project.

I think I know this, as I'm on the GCC steering committee since it's
inception.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Data loss at savannah.gnu.org

[David Miller]

From: Felix Zielcke 
Date: Tue, 02 Jun 2009 12:13:02 +0200

> Unfortunately Okuji already objected against git [0]

That was a year and a half ago, and how much has Okuji even made
postings to this mailing list lately?

Remind me what the definition of "maintainer" is?

I think the people actually doing the work of implementing things and
fixing bugs should make this decision, rather than someone who hasn't
the time to contribute in any way at all.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Data loss at savannah.gnu.org

[David Miller]

From: Pavel Roskin 
Date: Mon, 01 Jun 2009 09:37:23 -0400

> Since now having a repository affects out effectiveness, we may opt to
> switch to a git repository.

Yes, please, let's do this :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix sed quoting in sparc64 install script.

[David Miller]

Committed.

Index: ChangeLog
===
--- ChangeLog   (revision 2191)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2009-05-05  David S. Miller  
+
+   * util/sparc64/ieee1275/grub-install.in: Fix sed arg quoting.
+
 2009-05-05  Pavel Roskin  
 
* include/grub/dl.h [GRUB_UTIL]: Provide inline implementations
Index: util/sparc64/ieee1275/grub-install.in
===
--- util/sparc64/ieee1275/grub-install.in   (revision 2191)
+++ util/sparc64/ieee1275/grub-install.in   (working copy)
@@ -237,8 +237,8 @@
 grub_drive="`$grub_probe --target=drive --device ${grub_device}`"
 
 # Strip partition number
-install_drive="`echo ${install_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
-grub_drive="`echo ${grub_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
+install_drive="`echo ${install_drive} | sed -e 's/\([^\]\),[0-9]*/\1/g'`"
+grub_drive="`echo ${grub_drive} | sed -e 's/\([^\]\),[0-9]*/\1/g'`"
 if [ "x${grub_drive}" != "x${install_drive}" ] ; then
 uuid="`$grub_probe --target=fs_uuid --device ${grub_device}`"
 if [ "x${uuid}" = "x" ] ; then


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Provide grub_dl_ref() and grub_dl_unref() for GRUB_UTIL

[David Miller]

From: Pavel Roskin 
Date: Mon, 04 May 2009 20:13:24 -0400

> Hello!
> 
> The GRUB code is full of constructs like
> 
> #ifndef GRUB_UTIL
>   grub_dl_ref (my_mod);
> #endif
> 
> It's better to avoid having source files littered with preprocessor
> conditionals.  This patch implements grub_dl_ref() and grub_dl_unref()
> as inline functions when GRUB_UTIL is defined.
> 
> I'm not using the unused attribute to match the existing signature of
> those functions.
> 
> ChangeLog:
>   * include/grub/dl.h [GRUB_UTIL]: Provide inline implementations
>   of grub_dl_ref() and grub_dl_unref().  Remove preprocessor
>   conditionals around all callers.

Change looks great, but probably you want to explicitly mention
all of the C files where you got rid of the CPP conditional
tests.



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: IEEE1275 path name escaping...

[David Miller]

Ok, finally GRUB works also on my workstation.

These are the changes that allow GRUB to properly handle
"," characters in OF path names.

As we discussed about a month ago, when a "," appears in an
OF path name we escape it with "\".

So all of the real work is escaping OF paths as they are given
to GRUB, and then un-escaping them when ofdisk tries to open
them.

Committed.

PS: I plan to spend the next few days testing what we have now on
a variety of sparc64 systems to make sure all of the most obvious
problems get shaken out.

2009-05-04  David S. Miller  

* disk/ieee1275/ofdisk.c (compute_dev_path): New.
(grub_ofdisk_open): Use it to un-escape "," characters.
* kern/disk.c (find_part_sep): New.
(grub_disk_open): Use it to find the first non-escaped ','
character in the disk name.
* util/ieee1275/devicemap.c (escape_of_path): New.
(grub_util_emit_devicemap_entry): Use it.
* util/sparc64/ieee1275/grub-install.in: Update script to
strip partition specifiers properly by not triggering on
'\' escaped ',' characters.

Index: disk/ieee1275/ofdisk.c
===
--- disk/ieee1275/ofdisk.c  (revision 2188)
+++ disk/ieee1275/ofdisk.c  (working copy)
@@ -115,6 +115,38 @@
   return grub_devalias_iterate (dev_iterate);
 }
 
+static char *
+compute_dev_path (const char *name)
+{
+  char *devpath = grub_malloc (grub_strlen (name) + 2);
+  char *p, c;
+
+  if (!devpath)
+return NULL;
+
+  /* Un-escape commas. */
+  p = devpath;
+  while ((c = *name++) != '\0')
+{
+  if (c == '\\' && *name == ',')
+   {
+ *p++ = ',';
+ name++;
+   }
+  else
+   *p++ = c;
+}
+
+  if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_PARTITION_0))
+{
+  *p++ = ':';
+  *p++ = '0';
+}
+  *p++ = '\0';
+
+  return devpath;
+}
+
 static grub_err_t
 grub_ofdisk_open (const char *name, grub_disk_t disk)
 {
@@ -126,14 +158,10 @@
   char prop[64];
   grub_ssize_t actual;
 
-  devpath = grub_strndup (name, grub_strlen (name) + 2);
+  devpath = compute_dev_path (name);
   if (! devpath)
 return grub_errno;
 
-  /* To access the complete disk add `:0'.  */
-  if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_PARTITION_0))
-grub_strcat (devpath, ":0");
-
   op = ofdisk_hash_find (devpath);
   if (!op)
 op = ofdisk_hash_add (devpath);
Index: kern/disk.c
===
--- kern/disk.c (revision 2185)
+++ kern/disk.c (working copy)
@@ -215,10 +215,28 @@
   return 0;
 }
 
+/* Return the location of the first ',', if any, which is not
+   escaped by a '\'.  */
+static const char *
+find_part_sep (const char *name)
+{
+  const char *p = name;
+  char c;
+
+  while ((c = *p++) != '\0')
+{
+  if (c == '\\' && *p == ',')
+   p++;
+  else if (c == ',')
+   return p - 1;
+}
+  return NULL;
+}
+
 grub_disk_t
 grub_disk_open (const char *name)
 {
-  char *p;
+  const char *p;
   grub_disk_t disk;
   grub_disk_dev_t dev;
   char *raw = (char *) name;
@@ -238,7 +256,7 @@
   if (! disk->name)
 goto fail;
   
-  p = grub_strchr (name, ',');
+  p = find_part_sep (name);
   if (p)
 {
   grub_size_t len = p - name;
Index: util/sparc64/ieee1275/grub-install.in
===
--- util/sparc64/ieee1275/grub-install.in   (revision 2185)
+++ util/sparc64/ieee1275/grub-install.in   (working copy)
@@ -237,8 +237,8 @@
 grub_drive="`$grub_probe --target=drive --device ${grub_device}`"
 
 # Strip partition number
-install_drive="`echo ${install_drive} | sed -e s/,[0-9]*//g`"
-grub_drive="`echo ${grub_drive} | sed -e s/,[0-9]*//g`"
+install_drive="`echo ${install_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
+grub_drive="`echo ${grub_drive} | sed -e s/\([^\]\),[0-9]*/\1/g`"
 if [ "x${grub_drive}" != "x${install_drive}" ] ; then
 uuid="`$grub_probe --target=fs_uuid --device ${grub_device}`"
 if [ "x${uuid}" = "x" ] ; then
Index: util/sparc64/ieee1275/grub-setup.c
===
--- util/sparc64/ieee1275/grub-setup.c  (revision 2185)
+++ util/sparc64/ieee1275/grub-setup.c  (working copy)
@@ -56,7 +56,7 @@
  * device.  It also needs to know the initial block number of
  * 'core' (which is 'diskboot' concatenated with 'kernel' and
  * all the modules, this is created by grub-mkimage).  This resulting
- * 'boot' image is 512 bytes in size and is placed in the first block
+ * 'boot' image is 512 bytes in size and is placed in the second block
  * of a partition.
  *
  * The initial 'diskboot' block acts as a loader for the actual GRUB
@@ -100,6 +100,28 @@
   fflush (stdout);
 }
 
+static char *compute_dest_ofpath (const char *dest)
+{
+  int len = strlen (dest);
+  char *res, *p, c;
+
+  res = xmalloc (len);
+  p = res;
+

[PATCH]: Fix hangs and stalls on sparc64

[David Miller]

1) If there isn't a CDROM in the drive, trying to do an
   ieee1275 open() on a cdroom device hangs nearly indefinitely.

2) If you try to open the bare device "ide/disk" for example (with
   no "@X,Y" ID selector) this hangs for 5 seconds then spits out
   ugly errors about not being able to read disk labels etc.

So bypass these cases for now, we're only really interested in
the explicitly listed aliases anyways.

As for cdrom grub2 booting, I have some plans for this and I will
look into them after I get some feedback about some details of
OpenBoot from one of my engineering contacts at Sun.

Committed.

2009-05-04  David S. Miller  

* disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Bypass cdrom
devices, and do not traverse down under controller nodes.

Index: disk/ieee1275/ofdisk.c
===
--- disk/ieee1275/ofdisk.c  (revision 2185)
+++ disk/ieee1275/ofdisk.c  (working copy)
@@ -106,13 +106,9 @@
}
}
 
-  if (! grub_strcmp (alias->type, "block"))
+  if (! grub_strcmp (alias->type, "block") &&
+ grub_strcmp (alias->name, "cdrom"))
ret = hook (alias->name);
-  else if ((! grub_strcmp (alias->type, "scsi"))
-  || (! grub_strcmp (alias->type, "ide"))
-  || (! grub_strcmp (alias->type, "ata")))
-   /* Search for block-type children of these bus controllers.  */
-   ret = grub_children_iterate (alias->name, dev_iterate);
   return ret;
 }
 


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix sparc64 build.

[David Miller]

Please be more careful people.

2009-05-04  David S. Miller  

* conf/sparc64-ieee1275.rmk: Fix build due to missing '\'.

--- conf/sparc64-ieee1275.rmk   (revision 2184)
+++ conf/sparc64-ieee1275.rmk   (revision 2187)
@@ -113,12 +113,12 @@
kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c   \
kern/err.c kern/file.c kern/fs.c kern/loader.c kern/main.c  \
kern/misc.c kern/parser.c kern/partition.c kern/reader.c\
-   kern/rescue_reader.c kern/rescue_parser.c
+   kern/rescue_reader.c kern/rescue_parser.c   \
kern/term.c fs/fshelp.c \
kern/list.c kern/handler.c  \
lib/arg.c normal/cmdline.c  \
normal/completion.c \
-   normal/main.c normal/menu.c \
+   normal/main.c normal/menu.c \
normal/menu_text.c  \
normal/menu_entry.c normal/menu_viewer.c normal/misc.c  \
normal/color.c  \


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix ieee1275 iterator regression.

[David Miller]

When I converted this code over to user dynamically allocated
strings, I inserted a bug by passing the address of the string
pointer instead of the pointer itself.

Committed.

2009-05-04  David S. Miller  

* kern/ieee1275/openfw.c (grub_children_iterate): Fix string
pointer args to grub_ieee1275_get_property().

diff --git a/kern/ieee1275/openfw.c b/kern/ieee1275/openfw.c
index 7d65023..31296b1 100644
--- a/kern/ieee1275/openfw.c
+++ b/kern/ieee1275/openfw.c
@@ -78,7 +78,7 @@ grub_children_iterate (char *devpath,
   struct grub_ieee1275_devalias alias;
   grub_ssize_t actual;
 
-  if (grub_ieee1275_get_property (child, "device_type", &childtype,
+  if (grub_ieee1275_get_property (child, "device_type", childtype,
  sizeof childtype, &actual))
continue;
 
@@ -86,7 +86,7 @@ grub_children_iterate (char *devpath,
 &actual))
continue;
 
-  if (grub_ieee1275_get_property (child, "name", &childname,
+  if (grub_ieee1275_get_property (child, "name", childname,
  sizeof childname, &actual))
continue;
 


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Build warning fix.

[David Miller]

I just committed the following.

I see people talking about enabling -Werror, but nobody is
watching for even the most obvious new warning messages
when they commit new changes :-(

2009-05-03  David S. Miller  

* normal/menu.c: Include grub/parser.h

diff --git a/normal/menu.c b/normal/menu.c
index abf1b0f..e1d7edc 100644
--- a/normal/menu.c
+++ b/normal/menu.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Get a menu entry by its index in the entry list.  */
 grub_menu_entry_t


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mmap services

[David Miller]

From: "Vladimir 'phcoder' Serbinenko" 
Date: Thu, 30 Apr 2009 15:36:36 +0200

> Rediffed and reposted due to request by David Miller

I've looked these over and I'm completely OK with these
changes as long as at least basic testing occurs for
the BIOS, ACPI, and EFI cases that are effected by this
change.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Partitions can start at zero.

[David Miller]

From: Vladimir Serbinenko 
Date: Mon, 20 Apr 2009 18:53:35 +0200

> On Mon, Apr 20, 2009 at 2:30 AM, David Miller  wrote:
> 
>>
>> With Sun partitions, individual partitions can start at disk
>> address zero.  That's right, zero.
>>
>> This works because UFS and EXT{2,3,4} superblocks are offset
>> far enough into the partition that it won't overwrite the
>> disk label nor the boot block.
>>
>> I added an, arguably hackish, heuristic to handle this properly.
>> Basically if the OS device name does not end in a digit we'll believe
>> that a zero hdg.start value can be a partition.
>>
>> If anyone has a better way to handle this, let me know :-)
>>
> What about the way I proposed in thread on implementing nested partitions?

After some discussions with Vladimir on IRC, he agreed that
my change goes in for now until his nested partition work is
ready.

So I have committed this change.

GRUB works on sparc64 right now on the one test system I got
working tonight, a sparc64 virtualized Sun LDOM guest system.
In fact most systems should work as long as they don't have
"," characters in their block device OF path name.

I'm working on that problem now.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Handle virtual disk device names on powerpc/sparc64

[David Miller]

PowerPC and Sparc64 virtualized disks on hypervisor systems
are named /dev/vdiskX instead of /dev/vdX.  Handle this.

Committed.

2009-04-30  David S. Miller  

* util/hostdisk.c (convert_system_partition_to_system_disk):
Handle virtual disk devices named /dev/vdiskX as found on sparc
and powerpc.

diff --git a/util/hostdisk.c b/util/hostdisk.c
index aa41703..eaccb73 100644
--- a/util/hostdisk.c
+++ b/util/hostdisk.c
@@ -767,6 +767,13 @@ convert_system_partition_to_system_disk (const char 
*os_dev)
}
   
   /* If this is an IDE, SCSI or Virtio disk.  */
+  if (strncmp ("vdisk", p, 5) == 0
+ && p[5] >= 'a' && p[5] <= 'z')
+   {
+ /* /dev/vdisk[a-z][0-9]* */
+ p[6] = '\0';
+ return path;
+   }
   if ((strncmp ("hd", p, 2) == 0
   || strncmp ("vd", p, 2) == 0
   || strncmp ("sd", p, 2) == 0)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Handle lettered OF path partitions on sparc64.

[David Miller]

OpenBoot uses ":a", ":b", etc. partition specifiers instead
of the numbered ":1", ":2", etc. that the generic ieee1275
code expects.

Instead of cruddng up the generic ieee1275 code with this,
just convert in the sparc64 specific code beforehand.

Committed.

2009-04-30  David S. Miller  

* kern/sparc64/ieee1275/init.c (grub_machine_set_prefix): If
lettered partition specifier is found, convert to numbered.

diff --git a/kern/sparc64/ieee1275/init.c b/kern/sparc64/ieee1275/init.c
index 5114f76..699f963 100644
--- a/kern/sparc64/ieee1275/init.c
+++ b/kern/sparc64/ieee1275/init.c
@@ -64,8 +64,8 @@ grub_machine_set_prefix (void)
   if (grub_prefix[0] != '(')
 {
   char bootpath[IEEE1275_MAX_PATH_LEN];
+  char *prefix, *path, *colon;
   grub_ssize_t actual;
-  char *prefix, *path;
 
   if (grub_ieee1275_get_property (grub_ieee1275_chosen, "bootpath",
  &bootpath, sizeof (bootpath), &actual))
@@ -77,6 +77,17 @@ grub_machine_set_prefix (void)
}
 
   /* Transform an OF device path to a GRUB path.  */
+  colon = grub_strchr (bootpath, ':');
+  if (colon)
+   {
+ char *part = colon + 1;
+
+ /* Consistently provide numbered partitions to GRUB.
+OpenBOOT traditionally uses alphabetical partition
+specifiers.  */
+ if (part[0] >= 'a' && part[0] <= 'z')
+   part[0] = '1' + (part[0] - 'a');
+   }
   prefix = grub_ieee1275_encode_devname (bootpath);
 
   path = grub_malloc (grub_strlen (grub_prefix)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix up a few build warnings.

[David Miller]

I noticed these in the build, and they result from the fact
that grub_uint64_t is "unsigned long" and consequently
grub_addr_t and grub_disk_addr_t have this type as well.

Since grub_uint64_t can be either "long long" or "long" depending
on the platform, a cast is the best fix for now.

Committed.

2009-04-29  David S. Miller  

* commands/lsmmap.c (grub_cmd_lsmmap): Add casts to avoid printf
warnings.
* kern/ieee1275/openfw.c (grub_claimmap): Likewise.
* disk/ieee1275/ofdisk.c (grub_ofdisk_open, grub_ofdisk_close,
grub_ofdisk_read): Likewise, and deal similarly with the fact that
ihandles have a 32-bit type but need to be stored in a "void *".

diff --git a/commands/lsmmap.c b/commands/lsmmap.c
index 562ba21..4fe9a5a 100644
--- a/commands/lsmmap.c
+++ b/commands/lsmmap.c
@@ -30,7 +30,7 @@ grub_cmd_lsmmap (grub_command_t cmd __attribute__ ((unused)),
   int NESTED_FUNC_ATTR hook (grub_uint64_t addr, grub_uint64_t size, 
grub_uint32_t type)
 {
   grub_printf ("base_addr = 0x%llx, length = 0x%llx, type = 0x%x\n",
-  addr, size, type);
+  (long long) addr, (long long) size, type);
   return 0;
 }
   grub_machine_mmap_iterate (hook);
diff --git a/disk/ieee1275/ofdisk.c b/disk/ieee1275/ofdisk.c
index 202be24..e2c7867 100644
--- a/disk/ieee1275/ofdisk.c
+++ b/disk/ieee1275/ofdisk.c
@@ -155,7 +155,8 @@ grub_ofdisk_open (const char *name, grub_disk_t disk)
   goto fail;
 }
 
-  grub_dprintf ("disk", "Opened `%s' as handle %p.\n", op->devpath, (void *) 
dev_ihandle);
+  grub_dprintf ("disk", "Opened `%s' as handle %p.\n", op->devpath,
+   (void *) (unsigned long) dev_ihandle);
 
   if (grub_ieee1275_finddevice (op->devpath, &dev))
 {
@@ -185,7 +186,7 @@ grub_ofdisk_open (const char *name, grub_disk_t disk)
 
   /* XXX: Read this, somehow.  */
   disk->has_partitions = 1;
-  disk->data = (void *) dev_ihandle;
+  disk->data = (void *) (unsigned long) dev_ihandle;
   return 0;
 
  fail:
@@ -199,7 +200,7 @@ grub_ofdisk_close (grub_disk_t disk)
 {
   grub_dprintf ("disk", "Closing handle %p.\n",
(void *) disk->data);
-  grub_ieee1275_close ((grub_ieee1275_ihandle_t) disk->data);
+  grub_ieee1275_close ((grub_ieee1275_ihandle_t) (unsigned long) disk->data);
 }
 
 static grub_err_t
@@ -211,21 +212,21 @@ grub_ofdisk_read (grub_disk_t disk, grub_disk_addr_t 
sector,
 
   grub_dprintf ("disk",
"Reading handle %p: sector 0x%llx, size 0x%lx, buf %p.\n",
-   (void *) disk->data, sector, (long) size, buf);
+   (void *) disk->data, (long long) sector, (long) size, buf);
 
   pos = sector * 512UL;
 
-  grub_ieee1275_seek ((grub_ieee1275_ihandle_t) disk->data, (int) (pos >> 32),
- (int) pos & 0xUL, &status);
+  grub_ieee1275_seek ((grub_ieee1275_ihandle_t) (unsigned long) disk->data,
+ (int) (pos >> 32), (int) pos & 0xUL, &status);
   if (status < 0)
 return grub_error (GRUB_ERR_READ_ERROR,
   "Seek error, can't seek block %llu",
-  sector);
-  grub_ieee1275_read ((grub_ieee1275_ihandle_t) disk->data, buf,
- size * 512UL, &actual);
+  (long long) sector);
+  grub_ieee1275_read ((grub_ieee1275_ihandle_t) (unsigned long) disk->data,
+ buf, size * 512UL, &actual);
   if (actual != actual)
 return grub_error (GRUB_ERR_READ_ERROR, "Read error on block: %llu",
-  sector);
+  (long long) sector);
 
   return 0;
 }
diff --git a/kern/ieee1275/openfw.c b/kern/ieee1275/openfw.c
index b23149e..7d65023 100644
--- a/kern/ieee1275/openfw.c
+++ b/kern/ieee1275/openfw.c
@@ -238,7 +238,8 @@ grub_claimmap (grub_addr_t addr, grub_size_t size)
   if (! grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_REAL_MODE)
   && grub_map (addr, addr, size, 0x00))
 {
-  grub_printf ("map failed: address 0x%x, size 0x%x\n", addr, size);
+  grub_printf ("map failed: address 0x%llx, size 0x%llx\n",
+  (long long) addr, (long long) size);
   grub_ieee1275_release (addr, size);
   return -1;
 }


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Missing newline at end of file.

[David Miller]

The build had been warning about this for a few weeks now,
I finnaly got annoyed enough to fix it :-)

Committed.

2009-04-29  David S. Miller  

* normal/command.c: Add missing newline at end of file.

diff --git a/normal/command.c b/normal/command.c
index 863d45f..3296515 100644
--- a/normal/command.c
+++ b/normal/command.c
@@ -67,4 +67,4 @@ grub_command_execute (char *cmdline, int interactive)
 grub_set_more (0);
 
   return ret;
-}
\ No newline at end of file
+}


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix warning on ieee1275 platforms other than i386

[David Miller]

On powerpc and sparc compiling lsmmap.c gives a warning because
the mmap iterator function declaration isn't visible.

Others provide this via memory.h so let's make these platforms
do this as well by simply including ieee1275.h

The sparc64 build, at least, is now warning free for me.

Committed.

2009-04-29  David S. Miller  

* include/grub/powerpc/ieee1275/memory.h: Include ieee1275.h.
* include/grub/sparc64/ieee1275/memory.h: Likewise.

diff --git a/include/grub/powerpc/ieee1275/memory.h 
b/include/grub/powerpc/ieee1275/memory.h
index 23e282f..f8f2ff0 100644
--- a/include/grub/powerpc/ieee1275/memory.h
+++ b/include/grub/powerpc/ieee1275/memory.h
@@ -19,6 +19,8 @@
 #ifndef GRUB_MEMORY_MACHINE_HEADER
 #define GRUB_MEMORY_MACHINE_HEADER 1
 
+#include 
+
 #define GRUB_MACHINE_MEMORY_AVAILABLE  1
 
 #endif
diff --git a/include/grub/sparc64/ieee1275/memory.h 
b/include/grub/sparc64/ieee1275/memory.h
index c997f66..25e3100 100644
--- a/include/grub/sparc64/ieee1275/memory.h
+++ b/include/grub/sparc64/ieee1275/memory.h
@@ -19,6 +19,8 @@
 #ifndef GRUB_MEMORY_MACHINE_HEADER
 #define GRUB_MEMORY_MACHINE_HEADER 1
 
+#include 
+
 #define GRUB_MACHINE_MEMORY_AVAILABLE  1
 
 #endif


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Revision 2136 breaks two-disk configuarion

[David Miller]

From: Pavel Roskin 
Date: Mon, 27 Apr 2009 18:26:11 -0400

> On Sun, 2009-04-26 at 22:57 -0700, David Miller wrote:
> 
>> grub_disk_open() isn't used, but a grub_device_open() does occur
>> during the iterator that has us find the FS_UUID device.  This
>> happens search_fs_uuid().
>> 
>> If we don't do this, we leave a device reference open and dangling.
> 
> Then we should be using grub_device_close().  I've made a patch that
> keeps dev, not disk in the data field.  Unfortunately, the problem
> persists.  I could easily reproduce it on another machine by using a
> flash drive and qemu.
> 
> It's entirely possible that the problem is elsewhere.  But I have no
> experience debugging memory problems in GRUB, so it will take time
> before I find out.
> 
> Here's the patch.  It doesn't make the memory problem go away, but it
> makes the code nicer by using the same abstraction to open and close the
> disk.
> 

I like this patch, please commit it.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Re: Revision 2136 breaks two-disk configuarion

[David Miller]

From: Pavel Roskin 
Date: Mon, 27 Apr 2009 23:50:45 -0400

> On Mon, 2009-04-27 at 18:45 -0700, David Miller wrote:
> 
>> Thanks for fixing this Pavel.  I suspect this bug is why the close was
>> left as a NOP function all of this time.
> 
> Maybe.
> 
>> Please commit this as it seems you haven't already :-)
> 
> I was about to commit it when I realized that the same could be done
> using a reference counter in struct grub_partition.  It may be an
> overkill for this purpose, but maybe there will be more users of the
> partition table in the future.  Besides, this patch could set an
> example.  Please have a cursory look to make sure it's a good example.

I think it's overkill at the moment.

> +/* Return partition to be freed if it can be freed.  */
> +static inline grub_partition_t
> +grub_partition_unref (const grub_partition_t p)
> +{
> +  if (p && p->refcount-- <= 0)
> +return p;

If the reference count dips below zero, that should trigger
an assertion rather than giving the pointer to the caller
again which will potentially double-free memory or whatever.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Re: Revision 2136 breaks two-disk configuarion

[David Miller]

From: Pavel Roskin 
Date: Mon, 27 Apr 2009 21:37:52 -0400

> On Mon, 2009-04-27 at 18:26 -0400, Pavel Roskin wrote:
> 
>> It's entirely possible that the problem is elsewhere.  But I have no
>> experience debugging memory problems in GRUB, so it will take time
>> before I find out.
> 
> Done!  disk->partition should not be copied by reference.  This patch
> fixes the broken magic problem.  The issue with mixing device and disk
> functions could be addressed separately.
> 
> ChangeLog:
>   disk/fs_uuid.c (grub_fs_uuid_open): Allocate memory to copy
>   parent's partition, don't copy it by reference, as it gets freed
>   on close.

Thanks for fixing this Pavel.  I suspect this bug is why the close was
left as a NOP function all of this time.

Please commit this as it seems you haven't already :-)

I'll take a look at your other patch too.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Revision 2136 breaks two-disk configuarion

[David Miller]

From: Pavel Roskin 
Date: Mon, 27 Apr 2009 01:25:37 -0400

> Hello!
> 
> Since the revision 2136, I'm getting a non-fatal error message:
> 
> GRUB loading.
> Welcome to GRUB!
> 
> alloc magic is broken at 0x7fdaf20
> Aborted. Press any key to exit.
> 
> After pressing enter, the menu appears and I can boot from it.  The
> description of the revision is:
> 
>* disk/fs_uuid.c (grub_fs_uuid_close): Call grub_disk_close()
>on disk->data.
> 
> The patch looks wrong to me.  There are no calls to grub_disk_open() in
> disk/fs_uuid.c.  Other callers to grub_disk_close() call
> grub_disk_open() as well.

grub_disk_open() isn't used, but a grub_device_open() does occur
during the iterator that has us find the FS_UUID device.  This
happens search_fs_uuid().

If we don't do this, we leave a device reference open and dangling.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Faulty grub-mkdevicemap file

[David Miller]

From: BandiPat 
Date: Sat, 25 Apr 2009 15:29:11 -0400

> Here is the error when running grub-install:

I just checked in the following patch which will fix this
bug.

2009-04-26  David S. Miller  

* util/grub-mkdevicemap.c (make_device_map): Add missing
NESTED_FUNC_ATTR to process_device().

diff --git a/util/grub-mkdevicemap.c b/util/grub-mkdevicemap.c
index 4f544f8..ac8a390 100644
--- a/util/grub-mkdevicemap.c
+++ b/util/grub-mkdevicemap.c
@@ -42,9 +42,9 @@ make_device_map (const char *device_map, int floppy_disks)
   int num_fd = 0;
   FILE *fp;
 
-  auto int process_device (const char *name, int is_floppy);
+  auto int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy);
 
-  int process_device (const char *name, int is_floppy)
+  int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy)
   {
 grub_util_emit_devicemap_entry (fp, (char *) name,
is_floppy, &num_fd, &num_hd);


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: zfs preview

[David Miller]

From: Jordi Mallach 
Date: Sun, 26 Apr 2009 02:58:47 +0200

> He surely will, yes... if you take into account that phcoder /is/ Vladimir.

This reminds me that I've had some serious trouble
finding posting in the archives because his postings
show up under more than one name :-/

Unfortunately, email is certainly not his forte'


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Faulty grub-mkdevicemap file

[David Miller]

From: BandiPat 
Date: Sat, 25 Apr 2009 15:29:11 -0400

> Here is the error when running grub-install:
> 
> grub-install /dev/sda
> /usr/sbin/grub-install: line 203: 1362 Segmentation fault
> $grub_mkdevicemap --device-map=$device_map $no_floppy
> 
> This is using svn2140 release.

Can you please run grub-mkdevicemap with the proper arguments
under gdb and get a backtrace?

With that, I can fix this bug.

Thanks!


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Fix ieee1275 iteraters to stop when hook() returns non-zero.

[David Miller]

From: David Miller 
Date: Thu, 23 Apr 2009 03:33:18 -0700 (PDT)

> 2009-04-23  David S. Miller  
> 
>   * disk/ieee1275/nand.c (grub_nand_iterate): Return
>   grub_devalias_iterate() result instead of unconditional 0.
>   * disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Likewise.
>   Also, capture hook return value, either directly or via
>   grub_children_iterate(), and propagate to caller.
>   * include/grub/ieee1275/ieee1275.h (grub_devalias_iterate,
>   grub_children_iterate): Return value is now 'int' instead of
>   'grub_err_t'.
>   * kern/ieee1275/openfw.c (grub_children_iterate): Fix to behave
>   like a proper iterator, stopping when hooks return non-zero.
>   (grub_devalias_iterate): Likewise.

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Close parent device in grub_fs_uuid_close().

[David Miller]

From: David Miller 
Date: Thu, 23 Apr 2009 03:33:16 -0700 (PDT)

> 2009-04-23  David S. Miller  
> 
>   * disk/fs_uuid.c (grub_fs_uuid_close): Call grub_disk_close()
>   on disk->data.

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Don't hold raw device open when iterating down into partitions.

[David Miller]

From: David Miller 
Date: Thu, 23 Apr 2009 03:33:14 -0700 (PDT)

> 2009-04-23  David S. Miller  
> 
>   Avoiding openning same device multiple times in device iterator.
> 
>   * kern/device.c (grub_device_iterate): Define struct part_ent,
>   and use it to build a list of partitions in interate_disk() and
>   iterate_partition().

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: grub: Fix ieee1275 iteraters to stop when hook() returns non-zero.

[David Miller]

This is the third part of fixing FS_UUID on sparc64.

The IEEE1275 devalias and child iterators were not like true grub2
iterators, even though their users expected as such.

Instead of stopping on the first non-zero hook return, they gave
instead error codes and walked the entire list of objects
unconditionally, invoking hook on all of them.

This severely broke things like FS_UUID.  I very strongly doubt that
any powerpc user tried successfully using FS_UUID in grub2 due to this
issue.

2009-04-23  David S. Miller  

* disk/ieee1275/nand.c (grub_nand_iterate): Return
grub_devalias_iterate() result instead of unconditional 0.
* disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Likewise.
Also, capture hook return value, either directly or via
grub_children_iterate(), and propagate to caller.
* include/grub/ieee1275/ieee1275.h (grub_devalias_iterate,
grub_children_iterate): Return value is now 'int' instead of
'grub_err_t'.
* kern/ieee1275/openfw.c (grub_children_iterate): Fix to behave
like a proper iterator, stopping when hooks return non-zero.
(grub_devalias_iterate): Likewise.
---
 disk/ieee1275/nand.c |3 +-
 disk/ieee1275/ofdisk.c   |   11 +
 include/grub/ieee1275/ieee1275.h |4 +-
 kern/ieee1275/openfw.c   |   40 +
 4 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/disk/ieee1275/nand.c b/disk/ieee1275/nand.c
index ed50768..37427f8 100644
--- a/disk/ieee1275/nand.c
+++ b/disk/ieee1275/nand.c
@@ -44,8 +44,7 @@ grub_nand_iterate (int (*hook) (const char *name))
   return 0;
 }
 
-  grub_devalias_iterate (dev_iterate);
-  return 0;
+  return grub_devalias_iterate (dev_iterate);
 }
 
 static grub_err_t
diff --git a/disk/ieee1275/ofdisk.c b/disk/ieee1275/ofdisk.c
index a56433d..202be24 100644
--- a/disk/ieee1275/ofdisk.c
+++ b/disk/ieee1275/ofdisk.c
@@ -77,6 +77,8 @@ grub_ofdisk_iterate (int (*hook) (const char *name))
 
   int dev_iterate (struct grub_ieee1275_devalias *alias)
 {
+  int ret = 0;
+
   grub_dprintf ("disk", "disk name = %s\n", alias->name);
 
   if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_OFDISK_SDCARD_ONLY))
@@ -105,17 +107,16 @@ grub_ofdisk_iterate (int (*hook) (const char *name))
}
 
   if (! grub_strcmp (alias->type, "block"))
-   hook (alias->name);
+   ret = hook (alias->name);
   else if ((! grub_strcmp (alias->type, "scsi"))
   || (! grub_strcmp (alias->type, "ide"))
   || (! grub_strcmp (alias->type, "ata")))
/* Search for block-type children of these bus controllers.  */
-   grub_children_iterate (alias->name, dev_iterate);
-  return 0;
+   ret = grub_children_iterate (alias->name, dev_iterate);
+  return ret;
 }
 
-  grub_devalias_iterate (dev_iterate);
-  return 0;
+  return grub_devalias_iterate (dev_iterate);
 }
 
 static grub_err_t
diff --git a/include/grub/ieee1275/ieee1275.h b/include/grub/ieee1275/ieee1275.h
index ed02f52..751055f 100644
--- a/include/grub/ieee1275/ieee1275.h
+++ b/include/grub/ieee1275/ieee1275.h
@@ -166,9 +166,9 @@ int EXPORT_FUNC(grub_ieee1275_set_color) 
(grub_ieee1275_ihandle_t ihandle,
 int EXPORT_FUNC(grub_ieee1275_milliseconds) (grub_uint32_t *msecs);
 
 
-grub_err_t EXPORT_FUNC(grub_devalias_iterate)
+int EXPORT_FUNC(grub_devalias_iterate)
  (int (*hook) (struct grub_ieee1275_devalias *alias));
-grub_err_t EXPORT_FUNC(grub_children_iterate) (char *devpath,
+int EXPORT_FUNC(grub_children_iterate) (char *devpath,
  int (*hook) (struct grub_ieee1275_devalias *alias));
 grub_err_t EXPORT_FUNC(grub_machine_mmap_iterate)
  (int NESTED_FUNC_ATTR (*hook) (grub_uint64_t, grub_uint64_t, 
grub_uint32_t));
diff --git a/kern/ieee1275/openfw.c b/kern/ieee1275/openfw.c
index 83bac65..b23149e 100644
--- a/kern/ieee1275/openfw.c
+++ b/kern/ieee1275/openfw.c
@@ -32,36 +32,37 @@ enum grub_ieee1275_parse_type
 };
 
 /* Walk children of 'devpath', calling hook for each.  */
-grub_err_t
+int
 grub_children_iterate (char *devpath,
- int (*hook) (struct grub_ieee1275_devalias *alias))
+  int (*hook) (struct grub_ieee1275_devalias *alias))
 {
   grub_ieee1275_phandle_t dev;
   grub_ieee1275_phandle_t child;
   char *childtype, *childpath;
   char *childname, *fullname;
+  int ret = 0;
 
   if (grub_ieee1275_finddevice (devpath, &dev))
-return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Unknown device");
+return 0;
 
   if (grub_ieee1275_child (dev, &child))
-return grub_error (GRUB_ERR_BAD_DEVICE, "Device has no children");
+return 0;
 
   childtype = grub_malloc (IEEE1275_MAX_PROP_LEN);
   if (!childtype)
-return grub_errno;
+return 0;
   childpath = grub_malloc (IEEE1275_MAX_PATH_LEN);
   if (!childpath)
 {
   grub_free (childtype);
-  return grub_errno;
+  return 0;
 }
   childname = grub_malloc (IEEE1275_MA

[PATCH]: grub: Close parent device in grub_fs_uuid_close().

[David Miller]

This is the second part of fixing FS_UUID on sparc64.

Strangely, the FS_UUID close handler was empty.  This leaks
the parent disk and device object.

Fix by calling grub_disk_close() on the appropriate object.

2009-04-23  David S. Miller  

* disk/fs_uuid.c (grub_fs_uuid_close): Call grub_disk_close()
on disk->data.
---
 disk/fs_uuid.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/disk/fs_uuid.c b/disk/fs_uuid.c
index 125d29b..9d83bb8 100644
--- a/disk/fs_uuid.c
+++ b/disk/fs_uuid.c
@@ -97,6 +97,8 @@ grub_fs_uuid_open (const char *name, grub_disk_t disk)
 static void
 grub_fs_uuid_close (grub_disk_t disk __attribute((unused)))
 {
+  grub_disk_t parent = disk->data;
+  grub_disk_close (parent);
 }
 
 static grub_err_t
-- 
1.6.2.4



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: grub: Don't hold raw device open when iterating down into partitions.

[David Miller]

This is the first part in fixing FS_UUID on sparc64.  As explained
in some of my previous patch descriptions, you cannot open the
same device node multiple times concurrently in OpenBoot.

The two cases in grub2 which cause this situation were module
dependency handling (already fixed by me a week or so ago) and
FS_UUID.

There are a few layers involved here to get this right.

The first part we handle here is making the core grub device iterator
make a list of partitions to iterate hooks over.  Once it builds the
list, it invokes the hook until non-zero is returned, freeing up
all the resources along the way.

2009-04-23  David S. Miller  

Avoiding openning same device multiple times in device iterator.

* kern/device.c (grub_device_iterate): Define struct part_ent,
and use it to build a list of partitions in interate_disk() and
iterate_partition().
---
 kern/device.c |   58 ++--
 1 files changed, 43 insertions(+), 15 deletions(-)

diff --git a/kern/device.c b/kern/device.c
index 60f25c1..184c3a2 100644
--- a/kern/device.c
+++ b/kern/device.c
@@ -83,6 +83,12 @@ grub_device_iterate (int (*hook) (const char *name))
   auto int iterate_partition (grub_disk_t disk,
  const grub_partition_t partition);
   
+  struct part_ent
+  {
+struct part_ent *next;
+char *name;
+  } *ents = NULL;
+
   int iterate_disk (const char *disk_name)
 {
   grub_device_t dev;
@@ -95,11 +101,28 @@ grub_device_iterate (int (*hook) (const char *name))
return 0;
   
   if (dev->disk && dev->disk->has_partitions)
-   if (grub_partition_iterate (dev->disk, iterate_partition))
- {
-   grub_device_close (dev);
-   return 1;
- }
+   {
+ struct part_ent *p;
+ int ret = 0;
+
+ (void) grub_partition_iterate (dev->disk, iterate_partition);
+ grub_device_close (dev);
+
+ p = ents;
+ ents = NULL;
+ while (p != NULL)
+   {
+ struct part_ent *next = p->next;
+
+ if (!ret)
+   ret = hook (p->name);
+ grub_free (p->name);
+ grub_free (p);
+ p = next;
+   }
+
+ return ret;
+   }
 
   grub_device_close (dev);
   return 0;
@@ -108,27 +131,32 @@ grub_device_iterate (int (*hook) (const char *name))
   int iterate_partition (grub_disk_t disk, const grub_partition_t partition)
 {
   char *partition_name;
-  char *device_name;
-  int ret;
+  struct part_ent *p;
   
   partition_name = grub_partition_get_name (partition);
   if (! partition_name)
return 1;
-  
-  device_name = grub_malloc (grub_strlen (disk->name) + 1
-+ grub_strlen (partition_name) + 1);
-  if (! device_name)
+
+  p = grub_malloc (sizeof (*p));
+  if (!p)
+   return 1;
+
+  p->name = grub_malloc (grub_strlen (disk->name) + 1
++ grub_strlen (partition_name) + 1);
+  if (! p->name)
{
+ grub_free (p);
  grub_free (partition_name);
  return 1;
}
 
-  grub_sprintf (device_name, "%s,%s", disk->name, partition_name);
+  grub_sprintf (p->name, "%s,%s", disk->name, partition_name);
   grub_free (partition_name);
 
-  ret = hook (device_name);
-  grub_free (device_name);
-  return ret;
+  p->next = ents;
+  ents = p;
+
+  return 0;
 }
 
   /* Only disk devices are supported at the moment.  */
-- 
1.6.2.4



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Kill unused sparc64 file.

[David Miller]

Committed.

2009-04-23  David S. Miller  

* kern/sparc64/ieee1275/openfw.c: Unused, delete.

diff --git a/kern/sparc64/ieee1275/openfw.c b/kern/sparc64/ieee1275/openfw.c
deleted file mode 100644
index fe9ee96..000
--- a/kern/sparc64/ieee1275/openfw.c
+++ /dev/null
@@ -1,373 +0,0 @@
-/*  openfw.c -- Open firmware support functions.  */
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2003,2004,2005,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see .
- */
-
-#include 
-#include 
-#include 
-#include  /* Needed ?  */
-#include 
-
-enum grub_ieee1275_parse_type
-{
-  GRUB_PARSE_FILENAME,
-  GRUB_PARSE_PARTITION,
-};
-
-/* Walk children of 'devpath', calling hook for each.  */
-grub_err_t
-grub_children_iterate (char *devpath,
- int (*hook) (struct grub_ieee1275_devalias *alias))
-{
-  grub_ieee1275_phandle_t dev;
-  grub_ieee1275_phandle_t child;
-
-  grub_ieee1275_finddevice (devpath, &dev);
-  if (((signed) dev) == -1)
-return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Unknown device");
-
-  grub_ieee1275_child (dev, &child);
-  if (((signed) child) == -1)
-return grub_error (GRUB_ERR_BAD_DEVICE, "Device has no children");
-
-  do
-{
-  /* XXX: Don't use hardcoded path lengths.  */
-  char childtype[64];
-  char childpath[64];
-  char childname[64];
-  char fullname[64];
-  struct grub_ieee1275_devalias alias;
-  grub_ssize_t actual;
-
-  grub_ieee1275_get_property (child, "device_type", childtype,
- sizeof childtype, &actual);
-  if (actual == -1)
-   continue;
-
-  grub_ieee1275_package_to_path (child, childpath, sizeof childpath,
-&actual);
-  if (actual == -1)
-   continue;
-
-  grub_ieee1275_get_property (child, "name", childname,
- sizeof childname, &actual);
-  if (actual == -1)
-   continue;
-
-  grub_sprintf (fullname, "%s/%s", devpath, childname);
-
-  alias.type = childtype;
-  alias.path = childpath;
-  alias.name = fullname;
-  hook (&alias);
-}
-  while (grub_ieee1275_peer (child, &child));
-
-  return 0;
-}
-
-/* Iterate through all device aliases.  This function can be used to
-   find a device of a specific type.  */
-grub_err_t
-grub_devalias_iterate (int (*hook) (struct grub_ieee1275_devalias *alias))
-{
-  grub_ieee1275_phandle_t devalias;
-  char aliasname[32];
-  grub_ssize_t actual;
-  grub_ieee1275_cell_t flags;
-  struct grub_ieee1275_devalias alias;
-
-  if (grub_ieee1275_finddevice ("/aliases", &devalias))
-return -1;
-
-  aliasname[0] = '\0';
-
-  while (grub_ieee1275_next_property (devalias, aliasname, aliasname, &flags) 
!= -1
-&& ((signed) flags) != -1 )
-{
-  grub_ieee1275_phandle_t dev;
-  grub_ssize_t pathlen, typelen;
-  char *devpath, *devtype;
-
-  grub_dprintf ("devalias", "devalias name = %s\n", aliasname);
-  
-  /* The property `name' is a special case we should skip.  */
-  if (!grub_strcmp (aliasname, "name"))
- continue;
-  
-  grub_ieee1275_get_property_length (devalias, aliasname, &pathlen);
-  devpath = grub_malloc (pathlen);
-  if (! devpath)
-   return grub_errno;
-
-  if (grub_ieee1275_get_property (devalias, aliasname, devpath, pathlen,
- &actual))
-   {
-  grub_dprintf ("devalias", "get_property (%s) failed\n", aliasname);
- grub_free (devpath);
- continue;
-   }
-  
-  if (grub_ieee1275_finddevice (devpath, &dev) || ((signed) dev) == -1)
-   {
- grub_dprintf ("devalias", "finddevice (%s) failed\n", devpath);
- grub_free (devpath);
- continue;
-   }
-
-  grub_ieee1275_get_property_length (dev, "device_type", &typelen);
-  devtype = grub_malloc (typelen);
-  if (! devtype)
-  {
-grub_free (devpath);
-return grub_errno;
-  }
-  if (grub_ieee1275_get_property (dev, "device_type", devtype, typelen, 
&actual))
-   {
- grub_dprintf ("devalias", "get device type failed\n");
-  grub_free (devtype);
- grub_free (devpath);
- continue;
-   }
-
-  alias.name = aliasname;
-  alias.path= devpath;
-  alias.type = devtype;
-  if((*hook) (&alia

Re: [PATCH]: grub: Add sparc64 support code.

[David Miller]

From: David Miller 
Date: Sun, 19 Apr 2009 17:42:18 -0700 (PDT)

> 2009-04-19  David S. Miller  
> 
>   * util/sparc64/ieee1275/misc.c: New file.
>   * util/sparc64/ieee1275/grub-setup.c: New file.
>   * util/sparc64/ieee1275/grub-ofpathname.c: New file.
>   * util/sparc64/ieee1275/grub-mkimage.c: New file.
>   * util/sparc64/ieee1275/grub-install.in: New file.
>   * util/ieee1275/ofpath.c: New file.
>   * util/ieee1275/devicemap.c: New file.
>   * util/devicemap.c: New file.
>   * util/deviceiter.c: New file.
>   * kern/sparc64/ieee1275/init.c: New file.
>   * include/grub/util/ofpath.h: New file.
>   * include/grub/util/deviceiter.h: New file.
>   * util/grub-mkdevicemap.c: Include deviceiter.h.
>   Implement using grub_util_emit_devicemap_entry and
>   grub_util_iterate_devices.
>   * conf/i386-corebook.rmk: Build util/deviceiter.c and
>   util/devicemap.c into grub-mkdevicemap
>   * conf/i386-efi.rmk: Likewise.
>   * conf/i386-ieee1275.rmk: Likewise.
>   * conf/i386-pc.rmk: Likewise.
>   * conf/powerpc-ieee1275.rmk: Likewise.
>   * conf/sparc64-ieee1275.rmk: Add rules to build boot block
>   images and installation utilities.  Build kernel as image
>   instead of as elf binary.  Use common rules as much as possible.

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Exliminate fixed length string buffers in child and devalias iterators.

[David Miller]

From: David Miller 
Date: Sun, 19 Apr 2009 17:27:53 -0700 (PDT)

> 2009-04-19  David S. Miller  
> 
>   * include/grub/ieee1275/ieee1275.h (IEEE1275_MAX_PROP_LEN,
>   IEEE1275_MAX_PATH_LEN): Define.
>   * kern/ieee1275/openfw.c (grub_children_iterate): Dynamically
>   allocate 'childtype', 'childpath', 'childname', and 'fullname'.
>   (grub_devalias_iterate): Dynamically allocate 'aliasname' and
>   'devtype'.  Explicitly NULL terminate devalias expansion.

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Handle the case where the root node has size-cells but not address-cells.

[David Miller]

From: David Miller 
Date: Sun, 19 Apr 2009 17:24:54 -0700 (PDT)

> 2009-04-19  David S. Miller  
> 
>   * kern/ieee1275/mmap.c (grub_machine_mmap_iterate): If size_cells
>   is larger than address_cells, use that value for address_cells too.

Committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Partitions can start at zero.

[David Miller]

From: Vladimir Serbinenko 
Date: Mon, 20 Apr 2009 18:53:35 +0200

> On Mon, Apr 20, 2009 at 2:30 AM, David Miller  wrote:
> 
>>
>> With Sun partitions, individual partitions can start at disk
>> address zero.  That's right, zero.
>>
>> This works because UFS and EXT{2,3,4} superblocks are offset
>> far enough into the partition that it won't overwrite the
>> disk label nor the boot block.
>>
>> I added an, arguably hackish, heuristic to handle this properly.
>> Basically if the OS device name does not end in a digit we'll believe
>> that a zero hdg.start value can be a partition.
>>
>> If anyone has a better way to handle this, let me know :-)
>>
> What about the way I proposed in thread on implementing nested partitions?

Yes it seems that it should be able to handle this situation.

I cannot say %100 for sure until I see the code you end up
writing, of course :)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Partitions can start at zero.

[David Miller]

From: Vladimir Serbinenko 
Date: Mon, 20 Apr 2009 18:53:35 +0200

> On Mon, Apr 20, 2009 at 2:30 AM, David Miller  wrote:
> 
>>
>> With Sun partitions, individual partitions can start at disk
>> address zero.  That's right, zero.
>>
>> This works because UFS and EXT{2,3,4} superblocks are offset
>> far enough into the partition that it won't overwrite the
>> disk label nor the boot block.
>>
>> I added an, arguably hackish, heuristic to handle this properly.
>> Basically if the OS device name does not end in a digit we'll believe
>> that a zero hdg.start value can be a partition.
>>
>> If anyone has a better way to handle this, let me know :-)
>>
> What about the way I proposed in thread on implementing nested partitions?

Thanks for your feedback, I'll take a look at this.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add sparc64 support code.

[David Miller]

From: David Miller 
Date: Sun, 19 Apr 2009 17:45:21 -0700 (PDT)

> Ho hum, the grub-devel "posting size monster" is likely going
> to eat this one.

It actually allowed the posting, I was just impatient :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add sparc64 support code.

[David Miller]

From: David Miller 
Date: Sun, 19 Apr 2009 17:42:18 -0700 (PDT)

Ho hum, the grub-devel "posting size monster" is likely going
to eat this one.

If you want to review this patch, I've put a copy up at:

http://vger.kernel.org/~davem/0004-grub-Add-sparc64-support-code.patch

> Ok, this gets sparc64 building again and adds the necessary seperation
> of the mkdevicemap implementation so we can use escaped openfirmware
> path names instead of "(hdX)" and "(fdX)" as is customary on i386.
> a
> Code is added to convert OS path names into openfirmware device
> paths.  With some very simple changes, this code can be adapted
> to powerpc.  This is not done yet, but when it is then grub will
> no longer depend upon the 'ofpathname' program on powerpc.
> 
> We're pretty close to working on sparc64 with this patch.  What
> remains is:
> 
> 1) Fleshing out and implementing the OF path name escaping for
>device map entries.
> 
> 2) Fixing how FS UUID code can open the same device multiple times
>at once, which doesn't work on OpenBoot.
> 
> I have patches for #2 and will begin working on #1 now.
> 
> 2009-04-19  David S. Miller  
> 
>   * util/sparc64/ieee1275/misc.c: New file.
>   * util/sparc64/ieee1275/grub-setup.c: New file.
>   * util/sparc64/ieee1275/grub-ofpathname.c: New file.
>   * util/sparc64/ieee1275/grub-mkimage.c: New file.
>   * util/sparc64/ieee1275/grub-install.in: New file.
>   * util/ieee1275/ofpath.c: New file.
>   * util/ieee1275/devicemap.c: New file.
>   * util/devicemap.c: New file.
>   * util/deviceiter.c: New file.
>   * kern/sparc64/ieee1275/init.c: New file.
>   * include/grub/util/ofpath.h: New file.
>   * include/grub/util/deviceiter.h: New file.
>   * util/grub-mkdevicemap.c: Include deviceiter.h.
>   Implement using grub_util_emit_devicemap_entry and
>   grub_util_iterate_devices.
>   * conf/i386-corebook.rmk: Build util/deviceiter.c and
>   util/devicemap.c into grub-mkdevicemap
>   * conf/i386-efi.rmk: Likewise.
>   * conf/i386-ieee1275.rmk: Likewise.
>   * conf/i386-pc.rmk: Likewise.
>   * conf/powerpc-ieee1275.rmk: Likewise.
>   * conf/sparc64-ieee1275.rmk: Add rules to build boot block
>   images and installation utilities.  Build kernel as image
>   instead of as elf binary.  Use common rules as much as possible.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: grub: Partitions can start at zero.

[David Miller]

With Sun partitions, individual partitions can start at disk
address zero.  That's right, zero.

This works because UFS and EXT{2,3,4} superblocks are offset
far enough into the partition that it won't overwrite the
disk label nor the boot block.

I added an, arguably hackish, heuristic to handle this properly.
Basically if the OS device name does not end in a digit we'll believe
that a zero hdg.start value can be a partition.

If anyone has a better way to handle this, let me know :-)

2009-04-19  David S. Miller  

* util/hostdisk.c (device_is_wholedisk): New function.
(grub_util_biosdisk_get_grub_dev): Shortcut when hdg.start is
zero only if device_is_wholedisk() returns true.
---
 util/hostdisk.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/util/hostdisk.c b/util/hostdisk.c
index aa41703..b55d7fe 100644
--- a/util/hostdisk.c
+++ b/util/hostdisk.c
@@ -827,6 +827,16 @@ convert_system_partition_to_system_disk (const char 
*os_dev)
 }
 
 static int
+device_is_wholedisk (const char *os_dev)
+{
+  int len = strlen (os_dev);
+
+  if (os_dev[len - 1] < '0' || os_dev[len - 1] > '9')
+return 1;
+  return 0;
+}
+
+static int
 find_system_device (const char *os_dev)
 {
   int i;
@@ -961,7 +971,7 @@ grub_util_biosdisk_get_grub_dev (const char *os_dev)
 
 grub_util_info ("%s starts from %lu", os_dev, hdg.start);
 
-if (hdg.start == 0)
+if (hdg.start == 0 && device_is_wholedisk (os_dev))
   return name;
 
 grub_util_info ("opening the device %s", name);
-- 
1.6.2.3



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: grub: Exliminate fixed length string buffers in child and devalias iterators.

[David Miller]

I did a lot of extensive research, and had some conversations with a
few openboot engineers, to determine the top-end values for properties
and path lengths.

Using that I added some defines and got rid of the various
fixed size stack lock buffers used throughout the openfirmware
code.  We now use dynamic allocation instead, and all of those
ugly "XXX" comments can be removed.

Finally, this works around a long standing bug in OpenBoot wherein
device alias properties are not NULL terminated.  We allocate
an extra byte and explicitly put a NULL character there in that
extra byte at the end.

2009-04-19  David S. Miller  

* include/grub/ieee1275/ieee1275.h (IEEE1275_MAX_PROP_LEN,
IEEE1275_MAX_PATH_LEN): Define.
* kern/ieee1275/openfw.c (grub_children_iterate): Dynamically
allocate 'childtype', 'childpath', 'childname', and 'fullname'.
(grub_devalias_iterate): Dynamically allocate 'aliasname' and
'devtype'.  Explicitly NULL terminate devalias expansion.
---
 include/grub/ieee1275/ieee1275.h |3 ++
 kern/ieee1275/openfw.c   |   64 -
 2 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/include/grub/ieee1275/ieee1275.h b/include/grub/ieee1275/ieee1275.h
index 3b5139e..ed02f52 100644
--- a/include/grub/ieee1275/ieee1275.h
+++ b/include/grub/ieee1275/ieee1275.h
@@ -39,6 +39,9 @@ struct grub_ieee1275_mem_region
   unsigned int size;
 };
 
+#define IEEE1275_MAX_PROP_LEN  8192
+#define IEEE1275_MAX_PATH_LEN  256
+
 #ifndef IEEE1275_CALL_ENTRY_FN
 #define IEEE1275_CALL_ENTRY_FN(args) (*grub_ieee1275_entry_fn) (args)
 #endif
diff --git a/kern/ieee1275/openfw.c b/kern/ieee1275/openfw.c
index d70c3ba..83bac65 100644
--- a/kern/ieee1275/openfw.c
+++ b/kern/ieee1275/openfw.c
@@ -38,6 +38,8 @@ grub_children_iterate (char *devpath,
 {
   grub_ieee1275_phandle_t dev;
   grub_ieee1275_phandle_t child;
+  char *childtype, *childpath;
+  char *childname, *fullname;
 
   if (grub_ieee1275_finddevice (devpath, &dev))
 return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "Unknown device");
@@ -45,13 +47,33 @@ grub_children_iterate (char *devpath,
   if (grub_ieee1275_child (dev, &child))
 return grub_error (GRUB_ERR_BAD_DEVICE, "Device has no children");
 
+  childtype = grub_malloc (IEEE1275_MAX_PROP_LEN);
+  if (!childtype)
+return grub_errno;
+  childpath = grub_malloc (IEEE1275_MAX_PATH_LEN);
+  if (!childpath)
+{
+  grub_free (childtype);
+  return grub_errno;
+}
+  childname = grub_malloc (IEEE1275_MAX_PROP_LEN);
+  if (!childname)
+{
+  grub_free (childpath);
+  grub_free (childtype);
+  return grub_errno;
+}
+  fullname = grub_malloc (IEEE1275_MAX_PATH_LEN);
+  if (!fullname)
+{
+  grub_free (childname);
+  grub_free (childpath);
+  grub_free (childtype);
+  return grub_errno;
+}
+
   do
 {
-  /* XXX: Don't use hardcoded path lengths.  */
-  char childtype[64];
-  char childpath[64];
-  char childname[64];
-  char fullname[64];
   struct grub_ieee1275_devalias alias;
   grub_ssize_t actual;
 
@@ -76,6 +98,11 @@ grub_children_iterate (char *devpath,
 }
   while (grub_ieee1275_peer (child, &child));
 
+  grub_free (fullname);
+  grub_free (childname);
+  grub_free (childpath);
+  grub_free (childtype);
+
   return 0;
 }
 
@@ -85,13 +112,23 @@ grub_err_t
 grub_devalias_iterate (int (*hook) (struct grub_ieee1275_devalias *alias))
 {
   grub_ieee1275_phandle_t aliases;
-  char aliasname[32];
+  char *aliasname, *devtype;
   grub_ssize_t actual;
   struct grub_ieee1275_devalias alias;
 
   if (grub_ieee1275_finddevice ("/aliases", &aliases))
 return -1;
 
+  aliasname = grub_malloc (IEEE1275_MAX_PROP_LEN);
+  if (!aliasname)
+return grub_errno;
+  devtype = grub_malloc (IEEE1275_MAX_PROP_LEN);
+  if (!devtype)
+{
+  grub_free (aliasname);
+  return grub_errno;
+}
+
   /* Find the first property.  */
   aliasname[0] = '\0';
 
@@ -100,8 +137,6 @@ grub_devalias_iterate (int (*hook) (struct 
grub_ieee1275_devalias *alias))
   grub_ieee1275_phandle_t dev;
   grub_ssize_t pathlen;
   char *devpath;
-  /* XXX: This should be large enough for any possible case.  */
-  char devtype[64];
 
   grub_dprintf ("devalias", "devalias name = %s\n", aliasname);
 
@@ -111,9 +146,17 @@ grub_devalias_iterate (int (*hook) (struct 
grub_ieee1275_devalias *alias))
   if (!grub_strcmp (aliasname, "name"))
continue;
 
+  /* Sun's OpenBoot often doesn't zero terminate the device alias
+strings, so we will add a NULL byte at the end explicitly.  */
+  pathlen += 1;
+
   devpath = grub_malloc (pathlen);
   if (! devpath)
-   return grub_errno;
+   {
+ grub_free (devtype);
+ grub_free (aliasname);
+ return grub_errno;
+   }
 
   if (grub_ieee1275_get_property (aliases, aliasname, devpath, pathlen,

[PATCH]: grub: Handle the case where the root node has size-cells but not address-cells.

[David Miller]

Under OpenBoot on sparc64:

The value of the #address-cells property in the root node is the
default value of 2.  The value of the #size-cells property in the root
node is the non-default value 2. (NOTE: Since the #address-cells property
value in the root node is the default value 2, the property may or may
not exist since the absence of the property implies the default value.)

So the address-cells property may or may not be there in the root
device node.  However we can depend upon the size-cells property being
there, and equal to 2.

The easiest way to handle this in the current grub code is to check to
see if the size-cells value is larger than the address-cells value.
Since that is nonsensicle, when we see that situation we set the
address-cells value to be equal to size-cells.

2009-04-19  David S. Miller  

* kern/ieee1275/mmap.c (grub_machine_mmap_iterate): If size_cells
is larger than address_cells, use that value for address_cells too.
---
 kern/ieee1275/mmap.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kern/ieee1275/mmap.c b/kern/ieee1275/mmap.c
index 5b30dbb..317a121 100644
--- a/kern/ieee1275/mmap.c
+++ b/kern/ieee1275/mmap.c
@@ -38,6 +38,9 @@ grub_machine_mmap_iterate (int NESTED_FUNC_ATTR (*hook) 
(grub_uint64_t, grub_uin
   grub_ieee1275_get_integer_property (root, "#size-cells", &size_cells,
  sizeof size_cells, 0);
 
+  if (size_cells > address_cells)
+address_cells = size_cells;
+
   /* Load `/memory/available'.  */
   if (grub_ieee1275_finddevice ("/memory", &memory))
 return grub_error (GRUB_ERR_UNKNOWN_DEVICE,
-- 
1.6.2.3



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: Fix sparc64 linux loader command registry.

[David Miller]

This code needed to be updated to deal with the fact that
the whole rescue thing is not being used any more.

Committed.

2009-04-19  David S. Miller  

* loader/sparc64/ieee1275/linux.c: Include grub/command.h
(grub_rescue_cmd_linux): Rename to...
(grub_cmd_linux): and fix prototype.
(grub_rescue_cmd_initrd): Rename to...
(grub_cmd_initrd): and fix prototype.
(cmd_linux, cmd_initrd): New.
(GRUB_MOD_INIT(linux)): Use grub_register_command().
(GRUB_MOD_FINI(linux): Use grub_unregister_command().

diff --git a/loader/sparc64/ieee1275/linux.c b/loader/sparc64/ieee1275/linux.c
index 4912b97..4f5b3ce 100644
--- a/loader/sparc64/ieee1275/linux.c
+++ b/loader/sparc64/ieee1275/linux.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static grub_dl_t my_mod;
 
@@ -281,8 +282,9 @@ grub_linux_load64 (grub_elf_t elf)
   return grub_elf64_load (elf, offset_phdr, 0, 0);
 }
 
-void
-grub_rescue_cmd_linux (int argc, char *argv[])
+static grub_err_t
+grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
+   int argc, char *argv[])
 {
   grub_file_t file = 0;
   grub_elf_t elf = 0;
@@ -360,10 +362,13 @@ out:
   initrd_addr = 0;
   loaded = 1;
 }
+
+  return grub_errno;
 }
 
-void
-grub_rescue_cmd_initrd (int argc, char *argv[])
+static grub_err_t
+grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
+int argc, char *argv[])
 {
   grub_file_t file = 0;
   grub_ssize_t size;
@@ -421,6 +426,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
  fail:
   if (file)
 grub_file_close (file);
+
+  return grub_errno;
 }
 
 static void
@@ -495,20 +502,22 @@ fetch_translations (void)
 }
 
 
+static grub_command_t cmd_linux, cmd_initrd;
+
 GRUB_MOD_INIT(linux)
 {
   determine_phys_base ();
   fetch_translations ();
 
-  grub_rescue_register_command ("linux", grub_rescue_cmd_linux,
-   "load a linux kernel");
-  grub_rescue_register_command ("initrd", grub_rescue_cmd_initrd,
-   "load an initrd");
+  cmd_linux = grub_register_command ("linux", grub_cmd_linux,
+0, "load a linux kernel");
+  cmd_initrd = grub_register_command ("initrd", grub_cmd_initrd,
+ 0, "load an initrd");
   my_mod = mod;
 }
 
 GRUB_MOD_FINI(linux)
 {
-  grub_rescue_unregister_command ("linux");
-  grub_rescue_unregister_command ("initrd");
+  grub_unregister_command (cmd_linux);
+  grub_unregister_command (cmd_initrd);
 }


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Eliminating nested functions

[David Miller]

From: Colin D Bennett 
Date: Sat, 18 Apr 2009 08:57:33 -0700

> Probably passing a pointer to a local structure is the easiest way
> to do it in most cases if the iteration function needs to access
> some state, right?

Right.

The biggest surprise for me, easily, when reading the grub2 sources
for the first time was seeing all of this masterbation with nested
functions.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Eliminating nested functions

[David Miller]

From: Pavel Roskin 
Date: Fri, 17 Apr 2009 11:54:57 -0400

> I suggest that we eliminate all nested functions.

I support this completely.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-fstest build issue in grub2-r2071 +

[David Miller]

From: David Miller 
Date: Tue, 14 Apr 2009 01:53:00 -0700 (PDT)

> From: John Stanley 
> Date: Tue, 14 Apr 2009 05:17:44 -0400
> 
>> An update: I looked at the change between r2077 and r2104 and it looks
>> like the relevant code is util/hostdisk.c; I've attached a patch that
>> appears to fix the problem.
> 
> Sorry about that bug.
> 
> I did test that patch, I wonder why it worked for me :-)

I commited your fix with some minor coding style fixes.

Thanks!


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-fstest build issue in grub2-r2071 +

[David Miller]

From: John Stanley 
Date: Tue, 14 Apr 2009 05:17:44 -0400

> An update: I looked at the change between r2077 and r2104 and it looks
> like the relevant code is util/hostdisk.c; I've attached a patch that
> appears to fix the problem.

Sorry about that bug.

I did test that patch, I wonder why it worked for me :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub: Eliminate recursive reads of the same device in grub_dl_load_file().

[David Miller]

From: David Miller 
Date: Sun, 12 Apr 2009 23:56:11 -0700 (PDT)

> 
> Openfirmware block device drivers do not allow for multiple concurrent
> opens of the same device.  It simply does not work.
> 
> Fortunately grub doesn't actually need to do this, it just happens
> to do so.  Here is the fix for the case of module dependency handling.
> 
> The other case that hits this problem is in the FS_UUID support code.
> I have patches later which will fix that case too, but that one is a
> little more involved as we have to fix some bugs in the the ieee1275
> devalias iterator first (for one, it doesn't stop when the callback
> returns non-zero as every other iterator in grub2 does).
> 
> 2009-04-12  David S. Miller  
> 
>   * kern/dl.c (grub_dl_load_file): Close file immediately when
>   we are done using it.

I've committed this change as well.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Kill fixed device name length from make_device_name().

[David Miller]

From: David Miller 
Date: Sun, 12 Apr 2009 23:53:04 -0700 (PDT)

> make_device_name() uses an arbitrary value for the device name
> length, putting an arbitrary limit on such strings.
> 
> We can do better by calculating the length of this string precisely.
> 
> 2009-04-12  David S. Miller  
> 
>   * util/hostdisk.c (make_device_name): Do not make any assumptions
>   about the length of drive names.

This patch seems straightforward and no objections have been
raised, so I've commited the change.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[David Miller]

From: Pavel Roskin 
Date: Mon, 13 Apr 2009 08:51:36 -0400

> On Sun, 2009-04-12 at 23:53 -0700, David Miller wrote:
>> Should be self-explanatory, these tools will be used on sparc64 just
>> like they are on i386-pc
> 
> Fine with me.

Thanks for reviewing, committed.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Allow to control objcopy '-B' argument from foo.rmk files.

[David Miller]

From: Robert Millan 
Date: Mon, 13 Apr 2009 16:29:10 +0200

> On Sat, Apr 11, 2009 at 01:08:31AM -0700, David Miller wrote:
>> index 7dfb854..b4f1353 100644
>> --- a/conf/i386-pc.rmk
>> +++ b/conf/i386-pc.rmk
>> @@ -17,26 +17,31 @@ pkglib_IMAGES = boot.img diskboot.img kernel.img 
>> pxeboot.img lnxboot.img \
>>  boot_img_SOURCES = boot/i386/pc/boot.S
>>  boot_img_ASFLAGS = $(COMMON_ASFLAGS)
>>  boot_img_LDFLAGS = $(COMMON_LDFLAGS) $(TARGET_IMG_LDFLAGS) -Wl,-Ttext,7C00
>> +boot_img_IMG_FMT = binary
> 
> Wait, isn't raw format implicit in the _img_ part of the variable name?
> 
> If it was ELF, we'd have boot_elf_..., right?

We have "images" which match the foo_img_* pattern, modules,
scripts, and "everything else" which we call programs and
the foo_elf_* rules match.

Feel free to double-check my attempted interpretation of the
code in genmk.rb

Really, I am pretty sure this is the best way to handle this.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add sparc64 Linux kernel loader support.

[David Miller]

From: phcoder 
Date: Mon, 13 Apr 2009 10:58:13 +0200

> Really nice. I have no way of testing it but if it works it means that
> sparc64 port now has real life. We could even proclaim April, the 13th
> the annual GRUB2 SPARC64 day

Not really.

None of the openfirmware path handling changes are in,
as well as the sparc64 ieee1275 installation tools.

The port is only halfway there, at best.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[David Miller]

From: Chip Panarchy 
Date: Mon, 13 Apr 2009 17:40:22 +1000

> Hello
> 
> When you mention 'Sun Partition' what file-system are you specifying?
> 
> ZFS?
> UFS?

EXT3, but the sun "partition" support has to be there for grub tools
to even get at the filesystems at all.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH]: grub: Add sparc64 Linux kernel loader support.

[David Miller]

This adds the sparc64 loader for Linux kernels.

Committed.

2009-04-13 David S. Miller 

* include/grub/sparc64/ieee1275/loader.h: New file.
* include/grub/sparc64/ieee1275/memory.h: Likewise.
* include/grub/sparc64/kernel.h: Likewise.
* loader/sparc64/ieee1275/linux.c: Likewise.
---
 include/grub/sparc64/ieee1275/loader.h |   27 ++
 include/grub/sparc64/ieee1275/memory.h |   24 ++
 include/grub/sparc64/kernel.h  |   30 ++
 loader/sparc64/ieee1275/linux.c|  514 
 4 files changed, 595 insertions(+), 0 deletions(-)
 create mode 100644 include/grub/sparc64/ieee1275/loader.h
 create mode 100644 include/grub/sparc64/ieee1275/memory.h
 create mode 100644 include/grub/sparc64/kernel.h
 create mode 100644 loader/sparc64/ieee1275/linux.c

diff --git a/include/grub/sparc64/ieee1275/loader.h 
b/include/grub/sparc64/ieee1275/loader.h
new file mode 100644
index 000..12bb2a6
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/loader.h
@@ -0,0 +1,27 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_LOADER_MACHINE_HEADER
+#define GRUB_LOADER_MACHINE_HEADER 1
+
+/* The symbol shared between the normal mode and rescue mode
+   loader.  */
+void grub_rescue_cmd_linux (int argc, char *argv[]);
+void grub_rescue_cmd_initrd (int argc, char *argv[]);
+
+#endif /* ! GRUB_LOADER_MACHINE_HEADER */
diff --git a/include/grub/sparc64/ieee1275/memory.h 
b/include/grub/sparc64/ieee1275/memory.h
new file mode 100644
index 000..c997f66
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/memory.h
@@ -0,0 +1,24 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009 Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_MEMORY_MACHINE_HEADER
+#define GRUB_MEMORY_MACHINE_HEADER 1
+
+#define GRUB_MACHINE_MEMORY_AVAILABLE  1
+
+#endif
diff --git a/include/grub/sparc64/kernel.h b/include/grub/sparc64/kernel.h
new file mode 100644
index 000..9f404b0
--- /dev/null
+++ b/include/grub/sparc64/kernel.h
@@ -0,0 +1,30 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2005,2006,2007,2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_KERNEL_CPU_HEADER
+#define GRUB_KERNEL_CPU_HEADER 1
+
+#define GRUB_MOD_ALIGN 0x2000
+
+/* Non-zero value is only needed for PowerMacs.  */
+#define GRUB_MOD_GAP 0x0
+
+#define GRUB_KERNEL_CPU_PREFIX 0x2
+#define GRUB_KERNEL_CPU_DATA_END   0x42
+
+#endif
diff --git a/loader/sparc64/ieee1275/linux.c b/loader/sparc64/ieee1275/linux.c
new file mode 100644
index 000..4912b97
--- /dev/null
+++ b/loader/sparc64/ieee1275/linux.c
@@ -0,0 +1,514 @@
+/* linux.c - boot Linux */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2003, 2004, 2005, 2007, 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or

grub: Add ieee1275 interfaces for phys and virt memory allocation on sparc64.

[David Miller]

This adds the ieee1275 interfaces sparc64's openboot has for
allocating physical memory, creating mappings, etc.

We can't reuse any of the existing similar calls used by powerpc since
these use two cells for passing physical addresses (even though only
one of those cell slots is used, this is legacy carry over from 32-bit
sparc times).

Committed.

2009-04-13  David S. Miller  

* kern/sparc64/ieee1275/ieee1275.c: New file.
* include/grub/sparc64/ieee1275/ieee1275.h (IEEE1275_MAP_WRITE,
IEEE1275_MAP_READ, IEEE1275_MAP_EXEC, IEEE1275_MAP_LOCKED,
IEEE1275_MAP_CACHED, IEEE1275_MAP_SE, IEEE1275_MAP_GLOBAL,
IEEE1275_MAP_IE, IEEE1275_MAP_DEFAULT): Define.
(grub_ieee1275_map_physical, grub_ieee1275_claim_vaddr,
grub_ieee1275_alloc_physmem): Declare new exported functions.
---
 include/grub/sparc64/ieee1275/ieee1275.h |   22 +
 kern/sparc64/ieee1275/ieee1275.c |  124 ++
 2 files changed, 146 insertions(+), 0 deletions(-)
 create mode 100644 kern/sparc64/ieee1275/ieee1275.c

diff --git a/include/grub/sparc64/ieee1275/ieee1275.h 
b/include/grub/sparc64/ieee1275/ieee1275.h
index 1ef95f9..7626e93 100644
--- a/include/grub/sparc64/ieee1275/ieee1275.h
+++ b/include/grub/sparc64/ieee1275/ieee1275.h
@@ -24,4 +24,26 @@
 
 typedef grub_uint64_t grub_ieee1275_cell_t;
 
+/* Encoding of 'mode' argument to grub_ieee1275_map_physical() */
+#define IEEE1275_MAP_WRITE 0x0001 /* Writable */
+#define IEEE1275_MAP_READ  0x0002 /* Readable */
+#define IEEE1275_MAP_EXEC  0x0004 /* Executable */
+#define IEEE1275_MAP_LOCKED0x0010 /* Locked in TLB */
+#define IEEE1275_MAP_CACHED0x0020 /* Cacheable */
+#define IEEE1275_MAP_SE0x0040 /* Side-effects */
+#define IEEE1275_MAP_GLOBAL0x0080 /* Global */
+#define IEEE1275_MAP_IE0x0100 /* Invert Endianness */
+#define IEEE1275_MAP_DEFAULT   (IEEE1275_MAP_WRITE | IEEE1275_MAP_READ | \
+IEEE1275_MAP_EXEC | IEEE1275_MAP_CACHED)
+
+extern int EXPORT_FUNC(grub_ieee1275_map_physical) (grub_addr_t paddr,
+   grub_addr_t vaddr,
+   grub_size_t size,
+   grub_uint32_t mode);
+extern int EXPORT_FUNC(grub_ieee1275_claim_vaddr) (grub_addr_t vaddr,
+  grub_size_t size);
+extern int EXPORT_FUNC(grub_ieee1275_alloc_physmem) (grub_addr_t *paddr,
+grub_size_t size,
+grub_uint32_t align);
+
 #endif /* ! GRUB_IEEE1275_MACHINE_HEADER */
diff --git a/kern/sparc64/ieee1275/ieee1275.c b/kern/sparc64/ieee1275/ieee1275.c
new file mode 100644
index 000..438a171
--- /dev/null
+++ b/kern/sparc64/ieee1275/ieee1275.c
@@ -0,0 +1,124 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+
+/* Sun specific ieee1275 interfaces used by GRUB.  */
+
+int
+grub_ieee1275_map_physical (grub_addr_t paddr, grub_addr_t vaddr,
+   grub_size_t size, grub_uint32_t mode)
+{
+  struct map_physical_args
+  {
+struct grub_ieee1275_common_hdr common;
+grub_ieee1275_cell_t method;
+grub_ieee1275_cell_t ihandle;
+grub_ieee1275_cell_t mode;
+grub_ieee1275_cell_t size;
+grub_ieee1275_cell_t virt;
+grub_ieee1275_cell_t phys_high;
+grub_ieee1275_cell_t phys_low;
+grub_ieee1275_cell_t catch_result;
+  }
+  args;
+
+  INIT_IEEE1275_COMMON (&args.common, "call-method", 7, 1);
+  args.method = (grub_ieee1275_cell_t) "map";
+  args.ihandle = grub_ieee1275_mmu;
+  args.mode = mode;
+  args.size = size;
+  args.virt = vaddr;
+  args.phys_high = 0;
+  args.phys_low = paddr;
+  args.catch_result = (grub_ieee1275_cell_t) -1;
+
+  if (IEEE1275_CALL_ENTRY_FN (&args) == -1)
+return -1;
+  return args.catch_result;
+}
+
+int
+grub_ieee1275_claim_vaddr (grub_addr_t vaddr, grub_size_t size)
+{
+  struct claim_vaddr_args
+  {
+struct grub_ieee1275_common_hdr common;
+grub_ieee1275_cell_t method;
+grub_ieee1275_cell_t ihandle;
+grub_ieee1275_cell_t align;
+grub_ieee1275_cell_t size;
+grub_ieee12

[PATCH]: grub: Add revamped kernel startup code for sparc64.

[David Miller]

I've commited these changes.

2009-04-12 David S. Miller 

* kern/sparc64/ieee1275/init.c: Delete, replace with...
* kern/sparc64/ieee1275/crt0.S: assembler implementation.
* include/grub/sparc64/ieee1275/kernel.h: Declare grub_prefix[].
(GRUB_MOD_ALIGN, GRUB_MOD_GAP, GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE,
GRUB_KERNEL_MACHINE_KERNEL_IMAGE_SIZE,
GRUB_KERNEL_MACHINE_COMPRESSED_SIZE, GRUB_KERNEL_MACHINE_PREFIX,
GRUB_KERNEL_MACHINE_DATA_END): Define.
(grub_kernel_image_size, grub_total_module_size): Declare.
---
 include/grub/sparc64/ieee1275/kernel.h |   38 +-
 kern/sparc64/ieee1275/crt0.S   |   77 ++
 kern/sparc64/ieee1275/init.c   |  237 
 3 files changed, 112 insertions(+), 240 deletions(-)
 create mode 100644 kern/sparc64/ieee1275/crt0.S
 delete mode 100644 kern/sparc64/ieee1275/init.c

diff --git a/include/grub/sparc64/ieee1275/kernel.h 
b/include/grub/sparc64/ieee1275/kernel.h
index 0b6bce2..03a6314 100644
--- a/include/grub/sparc64/ieee1275/kernel.h
+++ b/include/grub/sparc64/ieee1275/kernel.h
@@ -1,6 +1,6 @@
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2005,2007  Free Software Foundation, Inc.
+ *  Copyright (C) 2005,2007,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -19,12 +19,44 @@
 #ifndef GRUB_KERNEL_MACHINE_HEADER
 #define GRUB_KERNEL_MACHINE_HEADER 1
 
+#define GRUB_MOD_ALIGN 0x2000
+
+/* Non-zero value is only needed for PowerMacs.  */
+#define GRUB_MOD_GAP 0x0
+
+/* The offset of GRUB_TOTAL_MODULE_SIZE.  */
+#define GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE  0x8
+
+/* The offset of GRUB_KERNEL_IMAGE_SIZE.  */
+#define GRUB_KERNEL_MACHINE_KERNEL_IMAGE_SIZE  0xc
+
+/* The offset of GRUB_COMPRESSED_SIZE.  */
+#define GRUB_KERNEL_MACHINE_COMPRESSED_SIZE0x10
+
+/* The offset of GRUB_PREFIX.  */
+#define GRUB_KERNEL_MACHINE_PREFIX 0x14
+
+/* End of the data section. */
+#define GRUB_KERNEL_MACHINE_DATA_END   0x114
+
+#ifndef ASM_FILE
+
 #include 
+#include 
+
+/* The size of kernel image.  */
+extern grub_int32_t grub_kernel_image_size;
+
+/* The total size of module images following the kernel.  */
+extern grub_int32_t grub_total_module_size;
+
+/* The prefix which points to the directory where GRUB modules and its
+   configuration file are located.  */
+extern char grub_prefix[];
 
 void EXPORT_FUNC (grub_reboot) (void);
 void EXPORT_FUNC (grub_halt) (void);
 
-/* Where grub-mkimage places the core modules in memory.  */
-#define GRUB_IEEE1275_MODULE_BASE 0x0030
+#endif /* ! ASM_FILE */
 
 #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
diff --git a/kern/sparc64/ieee1275/crt0.S b/kern/sparc64/ieee1275/crt0.S
new file mode 100644
index 000..4e67cbc
--- /dev/null
+++ b/kern/sparc64/ieee1275/crt0.S
@@ -0,0 +1,77 @@
+/* crt0.S - Startup code for the Sparc64.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+#include 
+#include 
+
+   .text
+   .align  4
+   .globl  _start
+_start:
+   ba  codestart
+nop
+
+   . = EXT_C(_start) + GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE
+
+VARIABLE(grub_total_module_size)
+   .word   0
+VARIABLE(grub_kernel_image_size)
+   .word   0
+VARIABLE(grub_compressed_size)
+   .word   0
+VARIABLE(grub_prefix)
+   /* to be filled by grub-mkimage */
+
+   /*
+*  Leave some breathing room for the prefix.
+*/
+
+   . = EXT_C(_start) + GRUB_KERNEL_MACHINE_DATA_END
+
+codestart:
+   /* Copy the modules past the end of the kernel image.
+* They are currently sitting in the BSS.
+*/
+   sethi   %hi(__bss_start), %o2
+   or  %o2, %lo(__bss_start), %o2
+   sethi   %hi(_end), %o3
+   or  %o3, %lo(_end), %o3
+   sethi   %hi(grub_total_module_size), %o4
+   lduw[%o4 + %lo(grub_total_module_size)], %o4
+1: lduw[%o2], %o5
+   stw %o5, [%o3]
+   subcc   %o4, 4, %o4
+   add %o2, 4, %o2
+   bne,pt  %icc, 1b
+add%o3, 4, %o3
+
+   /* Now it's safe to clear out the BSS.  */
+   sethi   %hi(__bss_start), %o2
+   or  %o2,