Re: localization of Grub
Hello, On Sep/29/2008, Vesa Jääskeläinen wrote: > Robert Millan wrote: > > On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: > >>> - gettextise the util tools, so they can be translated as normal > >>> programs. > >> ok! (I guess/hope that will be more "burocratic" work than new work) > > > > It _is_ technical work I think, but less fun than the other part :-/ > > > >> I don't expect to have time until 22th October (aprox.). I have more > >> interest in the second part (it's "newer") than first part, but first > >> part has a practical and fast effects with (I think) less investment. > > > > The second part also builds on the first, to some extent. I.e. if you want > > to test gettext support in GRUB itself, you need some strings to translate, > > and these are provided by the .mo files which are only built if the build > > system supports that, etc. > > Before you guy's go too deep in detail I would like to remind special > requirements for graphical user interface related to localization. first step (as long as I understood from Robert) would be adding localization (say... gettext support) to everything under grub2/util . This is userspace and I hope that standard gettext will be enough for there. What do you think? (I hope that will be enough because gettext is used in lot of places, even when I cannot find any RTL support after a fast Googling :-( ) > You can't just printf stuff to screen in there. There has to be some > changes in logic how information is presented to user. Currently there > is lot of printf's in the code to display information and that is not > going to be too pretty for graphical menu as we need to display some > kind of console on event when there is something to be displayed. well, I think that this printf's will not look pretty in any language (I mean, it's not a localization problem) > Also try to think how different languages differentiate for displaying > certain types of information. Here is some simple example. (Bear in mind > if there are grammatical errors or typos or so :)) > > (eng) "See Figure 2 in page 14 for more details.' -> (fin) "Sivulla 14 > olevassa kuvassa 2 on enemmän tietoa asiasta.' > > Please notice difference in order of arguments in the languages. gettext supports it > Also there are some weird scripts that change order of characters. In > example for some right-to-left scripts seem to have this feature. On > example that I think belongs to this group is hebrew where they normally > write from right-to-left, but for English (or foreign) texts are still > visually correct. > > In example: > "This is native 12and this is > English34, so weird." > > Would be something like: > ".rdiew os ,42and this is English31 evitan si sihT" > > So this subject really has more details than meets the eye in first > sight :) RTL problem is more about presentation, no? I will check how other programs do it. If the hebrew translator writes the correct translated string in the .po we will have it in Grub... but the alignment would be incorrect. It would look, for Left to Right people, like having everything aligned to the right. -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
Hi, On Sep/29/2008, Robert Millan wrote: > On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: > > > - gettextise the util tools, so they can be translated as normal > > > programs. > > > > ok! (I guess/hope that will be more "burocratic" work than new work) > > It _is_ technical work I think, but less fun than the other part :-/ When I said burocratic it was not like "Spanish burocracy" :-) I added locale support in another program (Python based). By "burocratic" I was thinking the part adding _() in all strings :-) (adding locale support to a non locale program has been quite much difficult and work... also I guess that there will be some problems adding locale dependencies in Grub too) > > I don't expect to have time until 22th October (aprox.). I have more > > interest in the second part (it's "newer") than first part, but first > > part has a practical and fast effects with (I think) less investment. > > The second part also builds on the first, to some extent. I.e. if you want > to test gettext support in GRUB itself, you need some strings to translate, > and these are provided by the .mo files which are only built if the build > system supports that, etc. I know -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Different keyborad layouts
Hello,
On Sep/29/2008, Vesa Jääskeläinen wrote:
> Carles Pina i Estany wrote:
> > Hello,
> >
> > I was thinking how we could have different keyboard layouts and after
> > have some ideas I sent some emails to Robert about this topic (who had some
> > better ideas :-) )
> >
> > Let me to explain here some plan/design. I would like to research on it
> > after some weeks, but if we need some discussion we could have it before
> > :-)
> >
> > (this is the result of some mails with Robert, so I'm copying/pasting and
> > changing some things, if I'm wrong Robert correct me!)
> >
> > Plan:
> > - in term/i386/pc/at_keyboard.c we could have something like this:
> >
> > static char english_map[] = { x, x, x };
> > char *map = english_map;
>
> Explain this a bit more...
>
> Remember that in some keyboard you need to press combos in order to
> generate some character. Like in Finnish keyboard you press alt-gr + e
> in order to generate euro sign (or alt-gr + 5). Also there are
> multi-keypress sequences like in order to make '^' this sign you have to
> press ctrl + '^' button and when released then press space. If you
> happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
> do not think this is the only keyboard with this feature. Also there is
> those dec input sequences like alt+number sequence. In example alt
> (pressed) + '6', '5' you get 'A'.
Spanish one is similar (well, vowells are easier to pronunce ;-) )
> > - have a new module with different layouts and variable hook
> >
> > - when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module
> > would
> > redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
> > de_map, etc.)
>
> I do not like the idea of using variable for this as it will most likely
> require loading of keymap definition form disk. So I would prefer something:
>
> insmod keymap
> keymap /boot/grub/keyboard/fi
from below problems (difficult to handle with the static char *map (that
we currenty have) plus this idea from you, my understanding is that we
should go having something like
/usr/share/keymaps/i386/qwerty/fi.kmap.gz (change your layout and
architecture, etc.)
So, the layout is not an easy char *map but it's a definition inside a
file. Maybe same one that Linux console?
> Also remember that you most likely want to play with scancodes when
> transcoding keysequences. I would propose that you convert those
> sequences to unicode so it would be easier to process. And if key is not
> possible to code as unicode then some kinda of keyevent with flag that
> this is eg. key up or something like that.
I take note.
All this "a bit more complicated case" if we want full layout in Grub.
Actually, what I miss in Grub is some characters like / ( ) = " ' < > :
; . & (I don't write texts in Grub :) )
I mean, we could:
a) do nothing (worst option?)
b) parcial implementation (still using the char *map with different
basic layouts)
c) full implementation, like Linux console
Do you have some strong opinion about what to do? I guess that c) is
better, do we need it?
Anyway, next days I will study how the Linux keymaps are working and are
handled.
--
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
El lun, 29-09-2008 a las 21:48 +0300, Vesa Jääskeläinen escribió: > Robert Millan wrote: > > On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: > >>> - gettextise the util tools, so they can be translated as normal > >>> programs. > >> ok! (I guess/hope that will be more "burocratic" work than new work) > > > > It _is_ technical work I think, but less fun than the other part :-/ > > > >> I don't expect to have time until 22th October (aprox.). I have more > >> interest in the second part (it's "newer") than first part, but first > >> part has a practical and fast effects with (I think) less investment. > > > > The second part also builds on the first, to some extent. I.e. if you want > > to test gettext support in GRUB itself, you need some strings to translate, > > and these are provided by the .mo files which are only built if the build > > system supports that, etc. > > Before you guy's go too deep in detail I would like to remind special > requirements for graphical user interface related to localization. > > You can't just printf stuff to screen in there. There has to be some > changes in logic how information is presented to user. Currently there > is lot of printf's in the code to display information and that is not > going to be too pretty for graphical menu as we need to display some > kind of console on event when there is something to be displayed. > > Also try to think how different languages differentiate for displaying > certain types of information. Here is some simple example. (Bear in mind > if there are grammatical errors or typos or so :)) > > (eng) "See Figure 2 in page 14 for more details.' -> (fin) "Sivulla 14 > olevassa kuvassa 2 on enemmän tietoa asiasta.' > > Please notice difference in order of arguments in the languages. > > Also there are some weird scripts that change order of characters. In > example for some right-to-left scripts seem to have this feature. On > example that I think belongs to this group is hebrew where they normally > write from right-to-left, but for English (or foreign) texts are still > visually correct. > > In example: > "This is native 12and this is > English34, so weird." > > Would be something like: > ".rdiew os ,42and this is English31 evitan si sihT" > > So this subject really has more details than meets the eye in first sight :) > Well, no one proposed a full implementation of the Unicode bi-di algorithm, and I think such a complex feat goes way beyond the development power behind GRUB right now. However, gettext does allow for the changes in the argument order you are worried about. Thus, there should be no problem translating the interface to LTR languages for the time being. -Habbit signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 summer code theme in debian?
Bean wrote: > On Wed, Sep 24, 2008 at 12:19 AM, Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote: >> J.Bakshi wrote: >>> In my debian lenny, the grub2 has very simple look. I know it can be tweak >>> to >>> get ubuntu style graphical grub2 interface. After searchine google I have >>> found the Grub2 summer code project 2008 and I have downloaded the theme >>> folder. But I can't understand how to include the theme file in grub.cfg. >>> Please let me know how to use those theme with grub.cfg. >> Integration of the Summer of Code 2008 codes are still work-in-progress. >> So at this time this is not possible. You have to wait a bit in order >> integration to be completed. > > Hi Vesa, > > The integration process seems to be halted, I wonder if there is > something wrong. IMO, we can commit the patch if there is no serious > breakage, we can fix minor issues later. I have been rather busy with other stuff. There is however some patches that could be looked independently. "pretty make patch" [PATCH] GSoC #03 Menu viewer interface [PATCH] GSoC #04 Multiple fallback entries [PATCH] GSoC #05 Menu entry class attribute - I do not like usage of '|' to separate arguments. So it would need to be either used as is, or menu parser would need work. I have started with those video subsystem improvements and have committed some of those (with modifications) already. And also some simple changes or bugfixes has already went. You can easily track patches with comments about commit that has went in. (I use threaded mail view to make things visually easy to process) There are still some video subsystem related stuff and then the new font engine that are next on my list. Also "[PATCH] GSoC #10 font tools" needs a bit discussion. And also can we use Lua for scripting (I think there is thread somewhere about that). Our second GSoC project for USB needs a bit more testing and perhaps some cleanups (Marco & Robert any comments?). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
Robert Millan wrote: > On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: >>> - gettextise the util tools, so they can be translated as normal >>> programs. >> ok! (I guess/hope that will be more "burocratic" work than new work) > > It _is_ technical work I think, but less fun than the other part :-/ > >> I don't expect to have time until 22th October (aprox.). I have more >> interest in the second part (it's "newer") than first part, but first >> part has a practical and fast effects with (I think) less investment. > > The second part also builds on the first, to some extent. I.e. if you want > to test gettext support in GRUB itself, you need some strings to translate, > and these are provided by the .mo files which are only built if the build > system supports that, etc. Before you guy's go too deep in detail I would like to remind special requirements for graphical user interface related to localization. You can't just printf stuff to screen in there. There has to be some changes in logic how information is presented to user. Currently there is lot of printf's in the code to display information and that is not going to be too pretty for graphical menu as we need to display some kind of console on event when there is something to be displayed. Also try to think how different languages differentiate for displaying certain types of information. Here is some simple example. (Bear in mind if there are grammatical errors or typos or so :)) (eng) "See Figure 2 in page 14 for more details.' -> (fin) "Sivulla 14 olevassa kuvassa 2 on enemmän tietoa asiasta.' Please notice difference in order of arguments in the languages. Also there are some weird scripts that change order of characters. In example for some right-to-left scripts seem to have this feature. On example that I think belongs to this group is hebrew where they normally write from right-to-left, but for English (or foreign) texts are still visually correct. In example: "This is native 12and this is English34, so weird." Would be something like: ".rdiew os ,42and this is English31 evitan si sihT" So this subject really has more details than meets the eye in first sight :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Different keyborad layouts
Carles Pina i Estany wrote:
> Hello,
>
> I was thinking how we could have different keyboard layouts and after
> have some ideas I sent some emails to Robert about this topic (who had some
> better ideas :-) )
>
> Let me to explain here some plan/design. I would like to research on it
> after some weeks, but if we need some discussion we could have it before
> :-)
>
> (this is the result of some mails with Robert, so I'm copying/pasting and
> changing some things, if I'm wrong Robert correct me!)
>
> Plan:
> - in term/i386/pc/at_keyboard.c we could have something like this:
>
> static char english_map[] = { x, x, x };
> char *map = english_map;
Explain this a bit more...
Remember that in some keyboard you need to press combos in order to
generate some character. Like in Finnish keyboard you press alt-gr + e
in order to generate euro sign (or alt-gr + 5). Also there are
multi-keypress sequences like in order to make '^' this sign you have to
press ctrl + '^' button and when released then press space. If you
happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
do not think this is the only keyboard with this feature. Also there is
those dec input sequences like alt+number sequence. In example alt
(pressed) + '6', '5' you get 'A'.
> - have a new module with different layouts and variable hook
>
> - when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module
> would
> redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
> de_map, etc.)
I do not like the idea of using variable for this as it will most likely
require loading of keymap definition form disk. So I would prefer something:
insmod keymap
keymap /boot/grub/keyboard/fi
Also remember that you most likely want to play with scancodes when
transcoding keysequences. I would propose that you convert those
sequences to unicode so it would be easier to process. And if key is not
possible to code as unicode then some kinda of keyevent with flag that
this is eg. key up or something like that.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: strange iso9660 bug
On Mon, Sep 29, 2008 at 11:07 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Mon, Sep 29, 2008 at 11:31:29AM +0300, Urja Rannikko wrote: >> On Sun, Sep 28, 2008 at 11:08 PM, Robert Millan <[EMAIL PROTECTED]> wrote: >> > >> > Hi, >> > >> > I was having a look at this iso9660 image: >> > >> > http://syllable.info/Syllable-0.6.4-LiveCD-1.1.iso.bz2 >> > >> > and GRUB seems to behave strangely with it. When its contents are listed >> > by >> > Linux, GRUB Legacy or isoinfo, you get a long list (the "real" data), but >> > when they're listed by GRUB 2, you get a short list with only 3 files: >> > >> > - autorun.inf >> > - some *.ico file >> > - readme.txt >> > >> >> One gets those for windows files in linux by doing: >> mount -o loop,norock -t iso9660 /tmp/syllable.iso /mnt/loop >> (that was my command line, YMMV) >> >> So i think that you need to support rockridge extensions to see the >> for linux content. > > Yup, that was it. > > So anyone feels like hacking rockridge? :-) Hi, Rockridge is supported in iso9660. However, the image file has three namespaces, iso9660, joliet and rockridge. Currently, the priority is: joliet > rockridge > iso9660 So only files in joliet is showed. It's possible to change priority, but what if we need to access files in the other namespace ? Perhaps we can control it with variables, for example: disable_joliet, disable_rockridge, etc. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: strange iso9660 bug
On Mon, Sep 29, 2008 at 11:31:29AM +0300, Urja Rannikko wrote: > On Sun, Sep 28, 2008 at 11:08 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I was having a look at this iso9660 image: > > > > http://syllable.info/Syllable-0.6.4-LiveCD-1.1.iso.bz2 > > > > and GRUB seems to behave strangely with it. When its contents are listed by > > Linux, GRUB Legacy or isoinfo, you get a long list (the "real" data), but > > when they're listed by GRUB 2, you get a short list with only 3 files: > > > > - autorun.inf > > - some *.ico file > > - readme.txt > > > > One gets those for windows files in linux by doing: > mount -o loop,norock -t iso9660 /tmp/syllable.iso /mnt/loop > (that was my command line, YMMV) > > So i think that you need to support rockridge extensions to see the > for linux content. Yup, that was it. So anyone feels like hacking rockridge? :-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
On Sun, Sep 28, 2008 at 11:49:54PM +0200, Carles Pina i Estany wrote: > > - gettextise the util tools, so they can be translated as normal > > programs. > > ok! (I guess/hope that will be more "burocratic" work than new work) It _is_ technical work I think, but less fun than the other part :-/ > I don't expect to have time until 22th October (aprox.). I have more > interest in the second part (it's "newer") than first part, but first > part has a practical and fast effects with (I think) less investment. The second part also builds on the first, to some extent. I.e. if you want to test gettext support in GRUB itself, you need some strings to translate, and these are provided by the .mo files which are only built if the build system supports that, etc. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] rename update-grub to update-grubcfg
Commited. Now we only have to think about our Debian package :) Am Mittwoch, den 24.09.2008, 15:54 +0200 schrieb Robert Millan: > On Wed, Sep 24, 2008 at 03:34:27PM +0200, Felix Zielcke wrote: > > Am Mittwoch, den 24.09.2008, 15:22 +0200 schrieb Robert Millan: > > > On Wed, Sep 24, 2008 at 01:04:03PM +0200, Felix Zielcke wrote: > > > > * util/update-grub_lib.in: Make it a stub to > > > > `grub-mkconfigig_lib.in'. > > > > > > Typo (mkconfigig). > > > > Oh thanks for spotting this. Seems like my concentration isn't that > > great currently :( > > > > > > -y) > > > > echo "$0: warning: Ignoring -y option (no longer needed)." >&2 > > > > > > This option was for compatibility with Debian's update-grub, it's not > > > needed in grub-mkconfig. > > > > Oh right. > > New patch attached. > > Looks fine, it can go in as far as I'm concerned. > > Nice work. > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Warning if grub.cfg not found
On Sun, Sep 28, 2008 at 11:41:02PM +0200, Carles Pina i Estany wrote:
>
> Hello,
>
> On Sep/28/2008, Robert Millan wrote:
> > On Sat, Sep 27, 2008 at 07:37:52PM +0200, Carles Pina i Estany wrote:
> > > --- normal/main.c (revision 1877)
> > > +++ normal/main.c (working copy)
> > > @@ -230,7 +230,13 @@
> > >/* Try to open the config file. */
> > >file = grub_file_open (config);
> > >if (! file)
> > > -return 0;
> > > +{
> >
> > This seems to include the possibility that file cannot be read simply
> > because
> > it's not there. Perhaps user intended so, and this shouldn't be reported as
> > an error.
>
> Do you mean that we could change:
> + grub_print_error ();
>
> by "grub_print_warning"?
>
> Or the whole point (warn the user if file is not there) is incorrect?
>
> If user doesn't want a grub.cfg, he/she could "touch grub.cfg" and
> that's all, no?
>
> If some user is miss-configuring Grub2 (pointing to an invalid device,
> partition, etc.) he will prefer to read "cannot find grub.cfg" than just
> see a shell (it's quite confusing, or it was for me when it happened :-)
> )
I think it's fine to tell the user about it, but without impliing that it
is an error. E.g. something like "grub.cfg not found, falling back to xxx",
without waiting for user confirmation.
What does everyone else think about this?
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Windows,grub and grub2
On Mon, Sep 29, 2008 at 1:18 PM, Viswesh S <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> - Original Message
>> From: Bean <[EMAIL PROTECTED]>
>> To: The development of GRUB 2
>> Sent: Tuesday, 23 September, 2008 7:20:49 PM
>> Subject: Re: Windows,grub and grub2
>>
>> On Tue, Sep 23, 2008 at 4:23 PM, Viswesh S wrote:
>> >
>> >
>> >
>> >
>> > - Original Message
>> >> From: Bean
>> >> To: The development of GRUB 2
>> >> Sent: Monday, 22 September, 2008 9:10:26 AM
>> >> Subject: Re: Windows,grub and grub2
>> >>
>> >> On Tue, Sep 9, 2008 at 2:00 PM, Viswesh S wrote:
>> >> > Below is the dump of screen output while chainloading the ntfsnew file.
>> >> > ***
>> >> > DI=CFF0 SI=07EE BP=1FF0 SP=1FE8 BX= DX= CX= AX=
>> >> > CS= SS= DS= ES= FG=0246 IP=7C57
>> >> >
>> >> > DI=7FF0 SI=07EE BP=1FF0 SP=7BF4 BX=55AA DX= CX= AX=0100 CX=07C0
>> >> > DS=07C0 ES= FG=0007 IP=0082
>> >> > **
>> >> > Could you please let me know the way to disassemble the binary file
>> >> > without
>> >> > any header.The way in which you decoded the boot record.
>> >> >
>> >> > Also one more thing to let you know is that,
>> >> >
>> >> > with the grub-1.96 ( without the chainloader patch of disk->dev->read()
>> >> > ) ,
>> >> > with windows2003 in partition 1 and linux in partition 3, when we
>> chainload,
>> >> > if we look at the partition table passed to another bootloader ie
>> >> > location
>> >> > 0x7be - we can see that it is junk, but the surprising point is that, in
>> >> > this case as I have mentioned in my first mail, windows boots up from
>> >> > grub2.So it is that the partition table is not required for the
>> >> > chainloader
>> >> > thing and just the boot record is sufficient
>> >>
>> >> Hi,
>> >>
>> >> Oh, sorry for another long delay. I disassemble the file with ida,
>> >> which is an amazing tool. I don't know if there is open source
>> >> alternative, please let me know if you find one.
>> >>
>> >> The output from ida is in masm format, I modify it a bit so that it
>> >> can be compiled using nasm. Please note that nasm doesn't generate the
>> >> same binary file as original one, but you can get an idea what it
>> >> does.
>> >>
>> >> From the output, the program fails at the second int 13 call, int
>> >> 13/ah = 48h. Although I notice that DL=0, which is not supposed to
>> >> happen. Perhaps you can add a grub_printf in grub_chainloader_boot to
>> >> show the value of boot drive:
>> >>
>> >> static grub_err_t
>> >> grub_chainloader_boot (void)
>> >> {
>> >> grub_printf ("boot_drive=%d\n", boot_drive);
>> >> grub_chainloader_real_boot (boot_drive, boot_part_addr);
>> >>
>> >> /* Never reach here. */
>> >> return GRUB_ERR_NONE;
>> >> }
>> >>
>> >> --
>> >> Bean
>> >>
>> >>
>> >
>> > Hi,
>> >
>> > The value of boot drive is 0x80.
>> >
>> > This was the same value in disk->drive also.
>>
>> Hi,
>>
>> Interesting, perhaps %dx is changed somewhere. Please try the
>> following patch, it dumps the value of %dx just before jumping to the
>> boot sector.
>>
>> --
>> Bean
>
> The patch works and now Windows is booting perfectly fine from Grub2.
>
> I will go through the assembly and try to understand what modifications you
> have done.So there is a problem in Grub2 code, which needs to be fixed ?
>
> Till this point, I was chainloading grub from Grub2 and then chainloading
> Windows2008 from it.
>
> Thanks for the consistent help till this point and for the future also.
Hi,
That's strange, the patch doesn't do anything except output the value of dx:
/* set up to pass boot drive */
popl%edx
+ movl%edx, %edi
/* ESI must point to a partition table entry */
popl%esi
callprot_to_real
.code16
+
+ push%dx
+ callhex_out
+ push%di
+ callhex_out
+
ljmp$0, $GRUB_MEMORY_MACHINE_BOOT_LOADER_ADDR
+
+hex_out:
+ pushw %bp
+ movw%sp, %bp
+ pushaw
+ movb$0xE, %ah
+ movw$7, %bx
+ movw$4, %cx
+ movw4(%bp), %dx
+1:
+ rol $4, %dx
+ movb%dl, %al
+ andb$0xF, %al
+ cmpb$10, %al
+ jb 2f
+ subb$('0'-'A'+10), %al
+2:
+ addb$'0', %al
+ int $0x10
+ loop1b
+ movb$' ', %al
+ int $0x10
+ popaw
+ popw%bp
+ ret $2
.code32
#include "../loader.S"
Perhaps you can try:
1, %edi is used as backup register in case %edx is changed by
prot_to_real, you can remove "movl %edx, %edi", "push %di", "call
hex_out" and see if it still works.
2, It's possible that the bug is position related, replace "push %dx",
"call hex_out" with equal number of nop and see what happens.
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/
Re: Bug-fix elf.c powerpc ieee1275
Explanation.
It seems to be a case of spurious line that got back into grub_elf32_load
and grub_elf64_load, nested function.
if (load_hook && load_hook (phdr, &load_addr))
return 1;
load_addr = phdr->p_paddr;
That sequence did not make sense to me, it overwrites the correct value of
load_addr from the preceding line.
Briefly -
with set debug=elf
Result -
for the bug -
..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8
fails to load kernel at 0x0 as expected.
the fix /* load_addr = phdr->p_paddr; */
..kernel/elf.c:429 Loading segment at 0x140 size 6ae0c8
loads kernel
--
Details -
Both 32bit ibook G4 and 64bit powerpc G5 were affected, and failed to load
linux kernel.
I rechecked and got some debug results to illustrate, hand copied from boot
screen.
I used grub_dprintf("elfpxw","phdr->p_paddr=%llx,
load_addr=%x\n",phdr->p_paddr,load_addr);
In grub_elf64_load as used by my powerpc64 g5.
The debugging outputs shown as they occur in sequence with the code (approx
line umbers)
if (load_hook && load_hook (phdr, &load_addr))
return 1;
..kernel/elf.c:421 phdr->p_paddr= c000 load_addr= 140
/* spurious line overwrites load_addr value from load_hook*/
load_addr = phdr->p_paddr;
..kernel/elf.c:424 phdr->p_paddr= c000 load_addr= 0
grub_dprintf ("elfpxw", "Loading segment at 0x%llx, size 0x%llx\n",
(unsigned long long) load_addr,
(unsigned long long) phdr->p_memsz);
..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8
- load kernel at 0x0 fails as expected
=
The correct result with /* load_addr = phdr->p_paddr;*/
if (load_hook && load_hook (phdr, &load_addr))
return 1;
phdr->p_paddr= c000 load_addr= 140
/*load_addr = phdr->p_paddr; */
phdr->p_paddr= c000 load_addr= 140
Loading segment at 0x140 size 6ae0c8
- load kernel at 0x140 succeeds.
=
peter cros.
On Mon, Sep 29, 2008 at 12:46 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 12:42:36AM +1000, peter cros wrote:
> > Hi,
> >
> > There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275),
> > causing load linux to fail on my powerpc64 g5 and ibook g4 32bit.
> >
> > Here is a diff of the fix I found necessary for rev 1878 (bug has existed
> in
> > previous versions).
> >
> > It was a one liner -
> >
> > diff -pu grubsvn/kern grubtry/kern/elf.c
> > -
> > --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000
> > +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000
> > @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e
> >
> > if (load_hook && load_hook (phdr, &load_addr))
> >return 1;
> > -load_addr = phdr->p_paddr;
> > +/** pxwdebug - not required - load_addr = phdr->p_paddr; **/
>
> Hi,
>
> Thanks for pointing this out. Unless someone understands your change,
> we'd need you to explain why this line isn't necessary, and why it was
> causing trouble.
>
> --
> Robert Millan
>
> The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
> how) you may access your data; but nobody's threatening your freedom: we
> still allow you to remove your data and not access it at all."
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: strange iso9660 bug
On Sun, Sep 28, 2008 at 11:08 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > Hi, > > I was having a look at this iso9660 image: > > http://syllable.info/Syllable-0.6.4-LiveCD-1.1.iso.bz2 > > and GRUB seems to behave strangely with it. When its contents are listed by > Linux, GRUB Legacy or isoinfo, you get a long list (the "real" data), but > when they're listed by GRUB 2, you get a short list with only 3 files: > > - autorun.inf > - some *.ico file > - readme.txt > One gets those for windows files in linux by doing: mount -o loop,norock -t iso9660 /tmp/syllable.iso /mnt/loop (that was my command line, YMMV) So i think that you need to support rockridge extensions to see the for linux content. -- urjaman ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
