Re: USB support merge (Re: [PATCH] (ata.mod) Fix ATAPI protocol)
Robert Millan r...@aybabtu.com writes: On Mon, Jan 19, 2009 at 11:15:41AM +0100, Marco Gerards wrote: Perhaps my USB code might help in some occasions for scsi.c, I am not completely sure if they are in sync. I sent in the USB code earlier. This code can be committed, although endianess is not handled correctly at all places. Hi, Alright then. I just checked in your last USB patch, after reviewing it: http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00604.html I agree it's best to commit it. It has a few minor problems, but this is much better than leaving it to bitrot. Then we can work on fixing them more easily. Thanks, I am happy it is merged now. It would help if people reported success/failure with USB support. Let's enumerate them again: - OHCI works on qemu but hasn't been tested on real hardware. - --enable-grub-emu-usb isn't yet known to work. - There might be endianess issues affecting powerpc (note: we aren't building it there yet, we'd have to move PCI support to i386.rmk first) It is even certain :-) - A few parts of it are marked XXX. I'll add one more to the list: keyboard support wasn't included in this patch. I'll look into your other pieces of code and retrieve a working keyboard driver. Right, this shouldn't be too hard as the code was there. But I have seen you submitted this already. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub_machine_fini on efi systems
Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
Remark 1: when loading OS grub has to call grub_efi_exit_boot_services which unloads efi nearly completely. On the other hand it shouldn't be called when returning with exit command. Perhaps we should split grub_machine_fini in two: one for preparing for OS and other for exiting. But then when one chainloads then grub_efi_exit_boot_services shouldn't be called. So I propose that loader function should cope with environment preparation. For cases when some preparation is needed independently of the type of loaded os (like setting 'map' hook) the best solution IMO would be preboot hooks. Remark 2: it should be clearly stated somewhere what the boot function may and may not use (e.g. boot function isn't allowed to read from disk, boot function may use grub_printf but not and so on) so that boot function conflicts neither with grub_machine_fini nor with preboot hooks Remark 3: in case of an error the non-returning boot function may return. I see 3 possible solution: a) forbid such an action. Use grub_fatal if really necessary b) loader should call a special function at point of noreturn c) delete the separation between returnable and not returnable booters. grub_machine_prepare_for_os and preboot_hooks in my proposition patch would then be extended with second function which is called upon the return to undo the action of the hook itself Regards Vladimir 'phcoder' Serbinenko phcoder wrote: Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). On Tue, Feb 17, 2009 at 9:53 AM, phcoder phco...@gmail.com wrote: Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros pxwp...@gmail.com wrote: There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). Hi, What's your frame buffer address, does grub_find_video_card detect it wrong ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
1. Initially - With 2GB RAM Imac8,1 has 256MB VRAM Radeon HD2600 1920x1200 MBP4,1 has 512MB VRAM Nvidia 8600 1920x1200 Imac8,1 grub boot linux shows Video frame buffer at 9052 and blank screen. MBP4,1 gives 9000 and scrambled video. 2. By overriding video_base to set it at 2GB grub_linux_setup_video () video_base = 0; grub_pci_iterate (grub_find_video_card); /* override */ video_base = 0x8000; Result - MBP gets readable text screens from kernel boot and init. Imac gets scrambled video (better than nothing) 3. further fiddling with grub_linux_setup_video() params-lfb_line_len = 8192; changed fromm 8192 to = width*4 gets clear script for Imac, but MBP wants 8192. 4. The results with 4GB RAM will differ I expect, and later effects unknown as the linux initialization is not completing (other issues with libata). On Tue, Feb 17, 2009 at 2:02 PM, Bean bean12...@gmail.com wrote: On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros pxwp...@gmail.com wrote: There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). Hi, What's your frame buffer address, does grub_find_video_card detect it wrong ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel