Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :)
> > For the sake of bisectability this really should be moved earlier; > otherwise at least patch "fix parameter to firmware calls" would > be wrong. > Even bigger problem is whether we want to run in LE mode at all. From what I understand (correct if I'm wrong) firmware calls remain big-endian and you need to switch back and forth between LE and BE when doing firmware calls. Byteswapping for the purpose of firmware calls is to be avoided as bugs are easy to slip through (in fact the byte-swapping isn't complete in proposed patches. (correct me if I'm wrong) these new patches cover a subset of already supported machines and don't add any user-visible feature and no new kernel type (LE kernel can be loaded from BE GRUB). Cross-compiling to BE from LE is easy (TARGET_CFLAGS=-EL). So it looks like this patch series adds a new high-maintenance-cost port covering only already supported machines and already supportred features. signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :)
В Wed, 26 Feb 2014 10:31:20 -0800 Ram Pai пишет: > From: Anton Blanchard > > powerpc64 is not necessarily BigEndian anymore! :) > > Signed-off-by: Ram Pai > --- > include/grub/powerpc/types.h | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/include/grub/powerpc/types.h b/include/grub/powerpc/types.h > index 7a2fc6b..ab138d4 100644 > --- a/include/grub/powerpc/types.h > +++ b/include/grub/powerpc/types.h > @@ -19,7 +19,7 @@ > #ifndef GRUB_TYPES_CPU_HEADER > #define GRUB_TYPES_CPU_HEADER1 > > -#ifdef __powerpc64le__ > +#ifdef __powerpc64__ > /* The size of void *. */ > #define GRUB_TARGET_SIZEOF_VOID_P8 > > @@ -33,8 +33,12 @@ > #define GRUB_TARGET_SIZEOF_LONG 4 > #endif > > -/* powerpc is big-endian. */ > -#define GRUB_TARGET_WORDS_BIGENDIAN 1 > +#ifdef __powerpc64le__ > +#undef GRUB_TARGET_WORDS_BIGENDIAN > +#else > +#define GRUB_TARGET_WORDS_BIGENDIAN 1 > +#endif > + For the sake of bisectability this really should be moved earlier; otherwise at least patch "fix parameter to firmware calls" would be wrong. > > > #endif /* ! GRUB_TYPES_CPU_HEADER */ ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 20/23] fix parameter to firmware calls
В Wed, 26 Feb 2014 10:31:19 -0800 Ram Pai пишет: > -#define IEEE1275_ADDR(x) (grub_uint32_t)(grub_addr_t)(x) > - > +#define IEEE1275_ADDR(x) > (grub_uint32_t)grub_cpu_to_be32((grub_addr_t)(x)) > +#define IEEE1275_VALUE(x) (grub_uint32_t)grub_cpu_to_be32(x) Same question - what about sparc64, is it safe to truncate values there? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 09/23] Fix warnings when building powerpc linux loader 64bit
В Wed, 26 Feb 2014 10:31:08 -0800
Ram Pai пишет:
> From: Anton Blanchard
>
> Fix warnings when building powerpc linux loader 64bit
>
> Signed-off-by: Ram Pai
> From: Anton Blanchard
> ---
> grub-core/loader/powerpc/ieee1275/linux.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/loader/powerpc/ieee1275/linux.c
> b/grub-core/loader/powerpc/ieee1275/linux.c
> index 4a14f66..3d6a61e 100644
> --- a/grub-core/loader/powerpc/ieee1275/linux.c
> +++ b/grub-core/loader/powerpc/ieee1275/linux.c
> @@ -141,8 +141,8 @@ grub_linux_boot (void)
>grub_ieee1275_set_property (grub_ieee1275_chosen, "bootargs", linux_args,
> grub_strlen (linux_args) + 1, &actual);
>
> - grub_dprintf ("loader", "Entry point: 0x%x\n", linux_entry);
> - grub_dprintf ("loader", "Initrd at: 0x%x, size 0x%x\n", initrd_addr,
> + grub_dprintf ("loader", "Entry point: 0x%lx\n", linux_entry);
I guess using PRIxGRUB_ADDR is more consistent - it can now be both 32 and 64
bits.
> + grub_dprintf ("loader", "Initrd at: 0x%lx, size 0x%lx\n", initrd_addr,
> initrd_size);
Ditto and PRIuGRUB_SIZE.
>grub_dprintf ("loader", "Boot arguments: %s\n", linux_args);
>grub_dprintf ("loader", "Jumping to Linux...\n");
> @@ -360,7 +360,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__
> ((unused)),
>if (addr == (grub_addr_t) -1)
> goto fail;
>
> - grub_dprintf ("loader", "Loading initrd at 0x%x, size 0x%x\n", addr, size);
> + grub_dprintf ("loader", "Loading initrd at 0x%lx, size 0x%lx\n", addr,
> size);
>
Ditto.
>if (grub_initrd_load (&initrd_ctx, argv, (void *) addr))
> goto fail;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 11/23] Fix powerpc setjmp/longjmp 64bit issues
В Wed, 26 Feb 2014 10:31:10 -0800 Ram Pai пишет: > From: Anton Blanchard > > Fix powerpc setjmp/longjmp 64bit issues > > Signed-off-by: Ram Pai > From: Anton Blanchard > --- > grub-core/lib/powerpc/setjmp.S | 94 > +++--- > 1 file changed, 52 insertions(+), 42 deletions(-) > > diff --git a/grub-core/lib/powerpc/setjmp.S b/grub-core/lib/powerpc/setjmp.S > index 716b563..51fcae9 100644 > --- a/grub-core/lib/powerpc/setjmp.S > +++ b/grub-core/lib/powerpc/setjmp.S > @@ -25,33 +25,43 @@ GRUB_MOD_LICENSE "GPLv3+" > > .text > > +#if defined( __powerpc64__ ) || defined( __powerpc64le__ ) Where is __powerpc64__ defined? Your previous patch adds only __powerpc64le__ and it does exist in current code as well? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 08/23] Add powerpc64 types
В Wed, 26 Feb 2014 10:31:07 -0800 Ram Pai пишет: > From: Anton Blanchard > > Add powerpc64 types > > Signed-off-by: Ram Pai > From: Anton Blanchard > --- > include/grub/powerpc/types.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/include/grub/powerpc/types.h b/include/grub/powerpc/types.h > index a098ae6..7a2fc6b 100644 > --- a/include/grub/powerpc/types.h > +++ b/include/grub/powerpc/types.h > @@ -19,11 +19,19 @@ > #ifndef GRUB_TYPES_CPU_HEADER > #define GRUB_TYPES_CPU_HEADER1 > > +#ifdef __powerpc64le__ > +/* The size of void *. */ > +#define GRUB_TARGET_SIZEOF_VOID_P8 > + > +/* The size of long. */ > +#define GRUB_TARGET_SIZEOF_LONG 8 > +#else > /* The size of void *. */ > #define GRUB_TARGET_SIZEOF_VOID_P4 > > /* The size of long. */ > #define GRUB_TARGET_SIZEOF_LONG 4 > +#endif > > /* powerpc is big-endian. */ > #define GRUB_TARGET_WORDS_BIGENDIAN 1 This sure can't be right on LE platform? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 06/23] Add IEEE1275_ADDR helper
В Wed, 26 Feb 2014 10:31:05 -0800 Ram Pai пишет: > From: Anton Blanchard > > If the target pointer size doesn't match the IEEE1275 cell size, we > need to cast twice to avoid a warning. > > > > +#define IEEE1275_ADDR(x) (grub_uint32_t)(grub_addr_t)(x) > + Should not this be conditional on sizeof(grub_ieee1275_cell_t)? Otherwise it seems to truncate value on platform where it is 64 bit (sparc64)? Is it possible that pointer does exceed 32 bits? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH 03/23] ignore .TOC. symbol
В Wed, 26 Feb 2014 10:31:02 -0800 Ram Pai пишет: > powerpc64 LE's linker knows how to handle the undefined > symbol .TOC. in grub modules. So just ignore that symbol during build. > > Signed-off-by: Ram Pai > --- > grub-core/gensyminfo.sh.in | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/grub-core/gensyminfo.sh.in b/grub-core/gensyminfo.sh.in > index 2e8716b..cad5af3 100644 > --- a/grub-core/gensyminfo.sh.in > +++ b/grub-core/gensyminfo.sh.in > @@ -34,4 +34,9 @@ else > fi > > # Print all undefined symbols used by module > -@TARGET_NM@ -u @TARGET_NMFLAGS_MINUS_P@ -p $module | sed "s@^\([^ > ]*\).*@undefined $modname \1@g" > +if test x"@GRUB_TARGET_CPU@" = xpowerpc64le; then > +#ignore the special .TOC. symbol on powerpc64le > +@TARGET_NM@ -u @TARGET_NMFLAGS_MINUS_P@ -p $module | grep -w -v '.TOC.' If I understand it correctly, it should rather be grep -F -w; just in case someone adds something like RTOCN? > +else > +@TARGET_NM@ -u @TARGET_NMFLAGS_MINUS_P@ -p $module > +fi | sed "s@^\([^ ]*\).*@undefined $modname \1@g" ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: pvgrub2 and old grub menu.lst
В Tue, 1 Apr 2014 15:46:22 +0800
Michael Chang пишет:
> While trying to boot xen pv guest with old grub config (menu.lst),
> the pvgrub2 loads it's menu successfully, but when you attemp to boot
> the kernel it failed with the following message.
>
> error: couldn't load file /boot/vmlinuz-3.0.76-0.11-xen.
> error: you need to load the kernel first.
>
> Press any key to continue..."
>
> The kernel is there and boots fine with pygrub.
>
> After some investigation, it boils down to the menu.lst has explicitly
> set it's root device to (hd0,1) and therefore the root device is not
> recognized by pvgrub2.
>
> title Xen -- SUSE Linux Enterprise Server 11 SP3 - 3.0.76-0.11
> root (hd0,1)
> kernel /boot/vmlinuz-3.0.76-0.11-xen root=/dev/xvda2 resume=/dev/xvda1
> splash=silent showopts initrd /boot/initrd-3.0.76-0.11.xen
>
> I'd like to know whether old grub configuration is considered or planned
> to work with pvgrub2 ? And is it a viable suggestion to have (hdX,Y) a
> valid xen disk name because it's quite common in some existing configs ?
>
I believe this technically should work; but this needs someone who
knows how Xen disks is mapped to hd number in legacy grub.
It would be something like (completely untested)
From: Andrey Borzenkov
Subject: [PATCH] accept also hdX as alias to native Xen disk name
This allows reusing legacy pvgrub menu.lst which is using hdX names.
Suggested-By: Michael Chang
---
grub-core/disk/xen/xendisk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
index 2b11c2a..c6c8ecc 100644
--- a/grub-core/disk/xen/xendisk.c
+++ b/grub-core/disk/xen/xendisk.c
@@ -70,9 +70,20 @@ grub_virtdisk_open (const char *name, grub_disk_t disk)
grub_uint32_t secsize;
char fdir[200];
char *buf;
+ int num = -1;
+ if (name[0] == 'h' && name[1] == 'd')
+{
+ num = grub_strtoul (hd+2, 0, 10);
+ if (grub_errno)
+ {
+ grub_errno = 0;
+ num = -1;
+ }
+}
for (i = 0; i < vdiskcnt; i++)
-if (grub_strcmp (name, virtdisks[i].fullname) == 0)
+if ((num != -1 && virtdisks[i].handle == num) ||
+grub_strcmp (name, virtdisks[i].fullname) == 0)
break;
if (i == vdiskcnt)
return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "not a virtdisk");
--
tg: (4afd010..) e/xen/hdX-compat (depends on: master)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Gamepad support, recognition and use as alternative to keyboard
On 01.04.2014 01:00, Tom Davies wrote: > Hi :) > Gamepad support for systems with neither mouse nor keyboard. > > Should this be posted as a "feature request" / "wish-list" item using > the bug-report system? Should we just put a tag in square brackets in > the subject-line, such as [feature-request]? > Doesn't really matter. Unless you provide a patch or someone else picks up the item, I don't think this is going to happen. I, and supposedly most other devs, don't even have the gamepad. > The users-support mailing list recently received a post from someone > asking how to set-up grub to work on a system that doesn't have a > keyboard and mouse. It's a gaming machine that might even find it > difficult or impossible to add a mouse or keyboard. Also with the > rise of Steam OS it might be that more people start needing Grub on > gaming devices. Is there already an alternative multi-boot > boot-loader for them? Is it likely to be difficult to get Grub2 to > detect such an unusual device? Each game-pad seems very different to > me so i wondered if that might be a factor? > > > My response was to just tell the original poster to post a bug-report > about it and look for another way of doing this in the shorter-term > but a couple of us are interested in knowing if that was good advice. > Regards from > Tom :) > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
pvgrub2 and old grub menu.lst
While trying to boot xen pv guest with old grub config (menu.lst), the pvgrub2 loads it's menu successfully, but when you attemp to boot the kernel it failed with the following message. error: couldn't load file /boot/vmlinuz-3.0.76-0.11-xen. error: you need to load the kernel first. Press any key to continue..." The kernel is there and boots fine with pygrub. After some investigation, it boils down to the menu.lst has explicitly set it's root device to (hd0,1) and therefore the root device is not recognized by pvgrub2. title Xen -- SUSE Linux Enterprise Server 11 SP3 - 3.0.76-0.11 root (hd0,1) kernel /boot/vmlinuz-3.0.76-0.11-xen root=/dev/xvda2 resume=/dev/xvda1 splash=silent showopts initrd /boot/initrd-3.0.76-0.11.xen I'd like to know whether old grub configuration is considered or planned to work with pvgrub2 ? And is it a viable suggestion to have (hdX,Y) a valid xen disk name because it's quite common in some existing configs ? Thanks, Michael ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
