[Qemu-devel] qemu vl.c vl.h cutils.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/10 19:36:39 Modified files: . : vl.c vl.h cutils.c Log message: always use mktimegm CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.356r2=1.357 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.291r2=1.292 http://cvs.savannah.gnu.org/viewcvs/qemu/cutils.c?cvsroot=qemur1=1.2r2=1.3
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Sat, 2007-11-03 at 01:18 +, Thiemo Seufer wrote: J. Mayer wrote: [snip] It restricts the letter to the ones historically allowed by Qemu, not to anything specific to any architecture or hw platform. What I like in my implementation, compared to the strchr..., is that it exactly tells the user which given device is incorrect. Well, here it makes no difference, strchr tells you exactly same as much. Yes, you're right. Was thinking about the original strspn. Instead of the check, the code could also allow everything from 'a' to 'z' and then just AND the produced 32bit bitmap with a machine defined bitmap that would be part of QEMUMachine. I guess we would better stop at 'n', because we can easily define a semantic for devices 'c' to 'm' (ie hard disk drives in a hardware platform specific order) but we have to define what means 'o' to 'z'. But I agree we would better extend it now, instead of having to rework it later... To select the network device to boot from would probably become a 'n' 'o' 'p' 'q' series. Seems OK. Can we say 'c' to 'm' is sufficient to address all disk drive cases or some more possibilities are needed for SCSI devices, or MTD devices boot ? Maybe 'u'... for USB, as most available machines know how to boot on USB, in the real world ? Or may we just consider 'c' to 'm' are sufficient and it's up to the machine to determine the real meaning of the letters, according to its implementation ? In this case, I think we would better provide a per-machine callback to handle the '?' case, printing an help on available boot devices letters and their meaning... [snip] Here's a second pass cleanup, adding the machine dependant checks for the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware firmware is able to boot from devices 'e' and 'f'. For the PowerPC machines, I choosed to try to boot from the first given usable device, some may not agree with this choice. It can be noticed that the available boot devices are not the same for PowerPC PreP, g3bw and mac99 machines. As I don't know the features and requirements for the other architectures, I prefered not to add any check for those ones. Most other machines ignore -boot and those that don't, shouldn't break from the introduced change, so please commit it when you feel ok with it. I'd like to know what are the feelings around about this patch and if there are specific requirements and/or problems for some platforms to be addressed before... I think the proposed scheme (and the implementation) is flexible enough to accomodate all relevant platforms. I think there are still a few problems here: 1/ it would not be easy to add a way to use the disk syntax as proposed here, but this could be useful. Another option could be added for this; or it could be part of the '-disk' syntax. 2/ doing a generic check in vl.c using the machine features would need a great rework. We then would have to first parse all options, then retrieve the machine features, then check all options according to those features. But this can be designed and done later 3/ it would be a great idea to provide a way to boot without any bloc device available. Embedded devices often just have a flash device or a ROM, then the checks done in vl.c to be sure there is a least one device present should be machine specific, imho. Then having an empty boot_devices string may not be a mistake. The two last point can sure be addressed separatly. For the first one, it seems to me that defining the way it has to be would be great: if it needs the -boot option to be extended or redesigned, I think the best would be to do it in the same patch... -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
Hi, On 01/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Thu, 2007-11-01 at 01:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote: On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. Here's a generic implementation that checks only the boot devices known to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the machine emulation code to work. When the machines will be able to check properly if the boot devices match the emulated hardware and the BIOS ABI, then it can be easily extended, changing one line, to allow boot from more devices. I think that this code should allow choosing to (try to...) boot from at least the 2 floppies and the 4 possible IDE devices. The consistency test could also be changed to add more drives if it seems to be needed. For consistency, I also made the boot_devices variable local to the main routine, as it's never used anywhere else. Thanks for the rework, I'm in favour of this patch. However, similar to the previous approach it still restricts the driver letters set and assumes that vl.c will be extended when some per-machine code needs more letters (which is okay with me, but I had understood that this was your concern). The letter check is equivalent to !strchr(BOOTCHARS, *p). It restricts the letter to the ones historically allowed by Qemu, not to anything specific to any architecture or hw platform. What I like in my implementation, compared to the strchr..., is that it exactly tells the user which given device is incorrect.
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Sat, 2007-11-03 at 01:01 +0100, andrzej zaborowski wrote: Hi, On 01/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Thu, 2007-11-01 at 01:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote: On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. Here's a generic implementation that checks only the boot devices known to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the machine emulation code to work. When the machines will be able to check properly if the boot devices match the emulated hardware and the BIOS ABI, then it can be easily extended, changing one line, to allow boot from more devices. I think that this code should allow choosing to (try to...) boot from at least the 2 floppies and the 4 possible IDE devices. The consistency test could also be changed to add more drives if it seems to be needed. For consistency, I also made the boot_devices variable local to the main routine, as it's never used anywhere else. Thanks for the rework, I'm in favour of this patch. However, similar to the previous approach it still restricts the driver letters set and assumes that vl.c will be extended when some per-machine code needs more letters (which is okay with me, but I had understood that this was your concern). The letter check is equivalent to !strchr(BOOTCHARS, *p). It
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
J. Mayer wrote: [snip] It restricts the letter to the ones historically allowed by Qemu, not to anything specific to any architecture or hw platform. What I like in my implementation, compared to the strchr..., is that it exactly tells the user which given device is incorrect. Well, here it makes no difference, strchr tells you exactly same as much. Yes, you're right. Was thinking about the original strspn. Instead of the check, the code could also allow everything from 'a' to 'z' and then just AND the produced 32bit bitmap with a machine defined bitmap that would be part of QEMUMachine. I guess we would better stop at 'n', because we can easily define a semantic for devices 'c' to 'm' (ie hard disk drives in a hardware platform specific order) but we have to define what means 'o' to 'z'. But I agree we would better extend it now, instead of having to rework it later... To select the network device to boot from would probably become a 'n' 'o' 'p' 'q' series. [snip] Here's a second pass cleanup, adding the machine dependant checks for the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware firmware is able to boot from devices 'e' and 'f'. For the PowerPC machines, I choosed to try to boot from the first given usable device, some may not agree with this choice. It can be noticed that the available boot devices are not the same for PowerPC PreP, g3bw and mac99 machines. As I don't know the features and requirements for the other architectures, I prefered not to add any check for those ones. Most other machines ignore -boot and those that don't, shouldn't break from the introduced change, so please commit it when you feel ok with it. I'd like to know what are the feelings around about this patch and if there are specific requirements and/or problems for some platforms to be addressed before... I think the proposed scheme (and the implementation) is flexible enough to accomodate all relevant platforms. Thiemo
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Thu, 2007-11-01 at 01:01 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote: On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. Here's a generic implementation that checks only the boot devices known to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the machine emulation code to work. When the machines will be able to check properly if the boot devices match the emulated hardware and the BIOS ABI, then it can be easily extended, changing one line, to allow boot from more devices. I think that this code should allow choosing to (try to...) boot from at least the 2 floppies and the 4 possible IDE devices. The consistency test could also be changed to add more drives if it seems to be needed. For consistency, I also made the boot_devices variable local to the main routine, as it's never used anywhere else. Thanks for the rework, I'm in favour of this patch. However, similar to the previous approach it still restricts the driver letters set and assumes that vl.c will be extended when some per-machine code needs more letters (which is okay with me, but I had understood that this was your concern). The letter check is equivalent to !strchr(BOOTCHARS, *p). It restricts the letter to the ones historically allowed by Qemu, not to anything specific to any architecture or hw platform. What I like in my implementation, compared to the strchr..., is that it exactly tells the user which given device is incorrect. This patch does not make the code simpler (in fact it's even more complicated as it does more generic consistency checks) but is generic and extensible, not breaking the previous
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. on a second thought I see how this may affect people using a non-default bios, but I guess 3 boot devices is better than only one that was possible without this patch. For most emulation targets, there still is a limit to 1. And the global limit to 3 is not even related to the PC spec, according to the code commited in pc.c. Then, imho, it cannot be better as it's inconsistent for the PC case and provides nothing in most cases. The limit of three is the max boot sequence length and the same (or lower) limit is already hardcoded in the machine initialisations where they deal with passing the sequence to the BIOS. What is the explanation of a global define to 1 for most target when you cannot globally know how the information will be exploited ? Yes, you can, it all sits in one repository and is part of the same project. vl.c doesn't have to deal with cases where, say, hw/pc.c is modified. In such case the author is supposed to update vl.c too. It would seem really more logical to allow the user to give all defined possible boot devices to the -boot parameter, then it's up to the target initialisation code or the BIOS (some target may use different BIOS with different ABIs for different usages...) to determine if the information can be used totally, partially or not at all. Let me give an example: what is the meaning of the -boot parameter for embedded board that can only boot from a flash device (see the ppc405_boards.c, for example...) ? My answer is that the user can always give the -boot parameter but it will just be ignored by the target specific code. This is exactly how it works in current CVS and also how it was before the commit. I will remove some of the check in vl.c though, so that machine code is free to allow the combinations that it likes. And the number of boot devices that may be usefull for a target is target or BIOS dependant. It's not in any way CPU architecture dependant, In qemu scope target arch is strictly connected with the target machines and BIOSes available. Regards
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. on a second thought I see how this may affect people using a non-default bios, but I guess 3 boot devices is better than only one that was possible without this patch. For most emulation targets, there still is a limit to 1. And the global limit to 3 is not even related to the PC spec, according to the code commited in pc.c. Then, imho, it cannot be better as it's inconsistent for the PC case and provides nothing in most cases. The limit of three is the max boot sequence length and the same (or lower) limit is already hardcoded in the machine initialisations where they deal with passing the sequence to the BIOS. Sure. And here is the only place you can hardcode / check anything like this, because this is _the_ place where you know what physical devices are actually emulated, and maybe (not always) what are the BIOS features, ... What is the explanation of a global define to 1 for most target when you cannot globally know how the information will be exploited ? Yes, you can, it all sits in one repository and is part of the same project. vl.c doesn't have to deal with cases where, say, hw/pc.c is modified. In such case the author is supposed to update vl.c too. There is no information about the emulated target reaching vl.c. In fact, in a ideal world, there should be not even a single #ifdef TARGET_xxx in that code. All the hardware emulation part is in the hardware library and the generic code has no idea about the actual emulated hardware. It even does not know if a family of device is supported or not by the target. In microcontrollers, you often have no bloc device. But nothing prevents you to add '-hda my_disk -boot c' to the command line... It would seem really more logical to allow the user to give all defined possible boot devices to the -boot parameter, then it's up to the target initialisation code or the BIOS (some target may use different BIOS with different ABIs for
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote: On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. Here's a generic implementation that checks only the boot devices known to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the machine emulation code to work. When the machines will be able to check properly if the boot devices match the emulated hardware and the BIOS ABI, then it can be easily extended, changing one line, to allow boot from more devices. I think that this code should allow choosing to (try to...) boot from at least the 2 floppies and the 4 possible IDE devices. The consistency test could also be changed to add more drives if it seems to be needed. For consistency, I also made the boot_devices variable local to the main routine, as it's never used anywhere else. This patch does not make the code simpler (in fact it's even more complicated as it does more generic consistency checks) but is generic and extensible, not breaking the previous patch and being consistent with the i386 machine BIOS features, as implemented now. The machine specific checks can be added later, for each target that need some. Another solution could be that every machine implements a callback that return a features bitmap, then the generic code could check if the given command line arguments (including the -boot option, but not only) are consistent with the emulated hardware platform. [...] -- J. Mayer [EMAIL PROTECTED] Never organized Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.353 diff -u -d -d -p -r1.353 vl.c --- vl.c 31 Oct 2007 01:54:03 - 1.353 +++ vl.c 31 Oct 2007 22:39:27 - @@ -162,12 +162,6 @@ static DisplayState display_state; int nographic; const char* keyboard_layout = NULL; int64_t ticks_per_sec; -#if defined(TARGET_I386) -#define MAX_BOOT_DEVICES 3 -#else -#define MAX_BOOT_DEVICES 1
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote: On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote: On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) MAX_BOOT_DEVICES doesn't limit the number of possible boot devices, it is only a limit for the length of the sequence given on command-line. The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. I personally wouldn't hardcode any limit but this code was submitted this way and doesn't limit any current functionality in any way, it extends it. I prefer the GNU/Hurd style code where no software limits are ever imposed and even the standard unix limits are undefined (e.g. no MAXPATHLEN), sometimes at significant cost. Imho, in that case, the only thing that can be check is that the given string contains only characters that can be valid devices in Qemu. Then, making boot_device a pointer directly assigned to optarg then check that all chars are = 'a' and 'c' + MAX_DISKS || chars == 'n' would greatly simplify the code. And this kind of check is the only valid one you can do in the generic code. Here's a generic implementation that checks only the boot devices known to be supported, ie 'a', 'c', 'd' and 'n', thus need no change in the machine emulation code to work. When the machines will be able to check properly if the boot devices match the emulated hardware and the BIOS ABI, then it can be easily extended, changing one line, to allow boot from more devices. I think that this code should allow choosing to (try to...) boot from at least the 2 floppies and the 4 possible IDE devices. The consistency test could also be changed to add more drives if it seems to be needed. For consistency, I also made the boot_devices variable local to the main routine, as it's never used anywhere else. Thanks for the rework, I'm in favour of this patch. However, similar to the previous approach it still restricts the driver letters set and assumes that vl.c will be extended when some per-machine code needs more letters (which is okay with me, but I had understood that this was your concern). The letter check is equivalent to !strchr(BOOTCHARS, *p). This patch does not make the code simpler (in fact it's even more complicated as it does more generic consistency checks) but is generic and extensible, not breaking the previous patch and being consistent with the i386 machine BIOS features, as implemented now. The machine specific checks can be added later, for each target that need some. Another solution could be that every machine implements a callback that return a features bitmap, then the generic code could check if the given command line arguments (including the -boot option, but not only) are consistent with the emulated hardware platform. This sounds like the correct
[Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.352r2=1.353 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.284r2=1.285 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/an5206.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/etraxfs.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf5208.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/palm.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.87r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/r2d.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.56r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.17r2=1.18
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. Furthermore, the patch breaks the coding style in some files (at least the ones I checked), which is weird. Seems _very_ strange to see it commited, then. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, on a second thought I see how this may affect people using a non-default bios, but I guess 3 boot devices is better than only one that was possible without this patch. Feel free to revert if you see any issues. Furthermore, the patch breaks the coding style in some files (at least the ones I checked), which is weird. I also tried to make sure that the original style in every file was retained (i.e. I wrapped lines crossing 80 chars), but again I may have missed something. Regards
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote: Hi, On 31/10/2007, J. Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/10/31 01:54:05 Modified files: . : vl.c vl.h hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c palm.c pc.c ppc405_boards.c ppc_chrp.c ppc_oldworld.c ppc_prep.c r2d.c realview.c shix.c spitz.c sun4m.c sun4u.c versatilepb.c Log message: Set boot sequence from command line (Dan Kenigsberg). There have been remarks about this patch that have not been addressed (not even answered, in fact). For example, the MAX_BOOT_DEVICES is set to 3 when more than 3 boot devices are possible to select (see the BOOTCHARS definition), which clearly shows the patch is not consistent. I double-checked to make sure all remarks made on qemu-devel were addressed, but I may have missed something. It was explained that the default bios supports only three boot devices, Then just take a look at the function boot_device2nibble in hw/pc.c. You can see 4 possibilities implemented here. And I think I've never seen a PC BIOS (on real machines, I mean) that don't allow more than 4 choices in last 5 years (and maybe much more...) The second point is that, as the legacy PC-BIOS is maybe the less versatile architecture that can be, putting limitations to the emulation model based on this spec seems to be a nonsense in Qemu, which is supposed to emulate _a lot_ of different architectures. As a matter of fact, a specific implementation (ie legacy PC target) should not lead to have hardcoded limits that would affect all other emulated targets. on a second thought I see how this may affect people using a non-default bios, but I guess 3 boot devices is better than only one that was possible without this patch. For most emulation targets, there still is a limit to 1. And the global limit to 3 is not even related to the PC spec, according to the code commited in pc.c. Then, imho, it cannot be better as it's inconsistent for the PC case and provides nothing in most cases. What is the explanation of a global define to 1 for most target when you cannot globally know how the information will be exploited ? It would seem really more logical to allow the user to give all defined possible boot devices to the -boot parameter, then it's up to the target initialisation code or the BIOS (some target may use different BIOS with different ABIs for different usages...) to determine if the information can be used totally, partially or not at all. Let me give an example: what is the meaning of the -boot parameter for embedded board that can only boot from a flash device (see the ppc405_boards.c, for example...) ? My answer is that the user can always give the -boot parameter but it will just be ignored by the target specific code. And the number of boot devices that may be usefull for a target is target or BIOS dependant. It's not in any way CPU architecture dependant, then the MAX_BOOT_DEVICES as it is implemented is false for the legacy PC architecture and has no meaning for all other cases. Feel free to revert if you see any issues. I don't think it breaks anything, then now that it's commited, it seems more urgent to see the patch reworked to make it consistent and really usable in all cases (PC is not the only Qemu target !) than to revert and generate CVS noise... Furthermore, the patch breaks the coding style in some files (at least the ones I checked), which is weird. I also tried to make sure that the original style in every file was retained (i.e. I wrapped lines crossing 80 chars) Apparently, not totally. (including 80 chars wrapping lines). -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu vl.c vl.h linux-user/main.c target-arm/cpu...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/12 06:47:46 Modified files: . : vl.c vl.h linux-user : main.c target-arm : cpu.h helper.c target-mips: cpu.h target-ppc : cpu.h target-sparc : cpu.h Log message: Unify '-cpu ?' option. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.347r2=1.348 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.277r2=1.278 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.131r2=1.132 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemur1=1.34r2=1.35 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.78r2=1.79 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.52r2=1.53
[Qemu-devel] qemu vl.c vl.h hw/mips_malta.c hw/mips_pica61.c...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/10/05 13:08:35 Modified files: . : vl.c vl.h hw : mips_malta.c mips_pica61.c mips_r4k.c pc.c ppc405_boards.c ppc_chrp.c ppc_prep.c shix.c sun4m.c sun4u.c Log message: New '-bios' option, used to select an alternate BIOS image from bios_dir. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.345r2=1.346 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.273r2=1.274 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.44r2=1.45 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.85r2=1.86 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.43r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.43r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.51r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.20r2=1.21
[Qemu-devel] qemu vl.c vl.h vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/25 01:35:38 Modified files: . : vl.c vl.h vnc.c Log message: Refactor VNC server setup API, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.331r2=1.332 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.261r2=1.262 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.14r2=1.15
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:56:03 Modified files: . : vl.c vl.h Log message: Rework alarm timer infrastrucure, by Luca Tettamanti. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.323r2=1.324 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.260r2=1.261
Re: [Qemu-devel] qemu vl.c vl.h hw/arm_boot.c
Hello Andrzej, Saturday, July 28, 2007, 1:08:46 AM, you wrote: CVSROOT:/sources/qemu [] Log message: Optionally setup old style linux bootparams for -kernel, by Juergen Lock. With such kind of options being merged, any chance that my old patch to override ARM MTYPE from command line can be merged too? CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.321r2=1.322 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.256r2=1.257 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.7r2=1.8 -- Best regards, Paulmailto:[EMAIL PROTECTED]
Re: [Qemu-devel] qemu vl.c vl.h hw/arm_boot.c
Hi, On 29/07/07, Paul Sokolovsky [EMAIL PROTECTED] wrote: Saturday, July 28, 2007, 1:08:46 AM, you wrote: CVSROOT:/sources/qemu [] Log message: Optionally setup old style linux bootparams for -kernel, by Juergen Lock. With such kind of options being merged, any chance that my old patch to override ARM MTYPE from command line can be merged too? As I mentioned I'm quite sure your kernel from a different machine won't boot unmodified on any of the currently supported boards even if the MTYPE is changed. Add a new board description to boot a kernel from that board (QEMU isn't suffering an overflow of different machines now). I'm not saying your patch can't be merged. I don't see how the -old-param option is related, it makes the spitz emulator appear closer to the real hardware. Regards
[Qemu-devel] qemu vl.c vl.h hw/arm_boot.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/07/27 22:08:46 Modified files: . : vl.c vl.h hw : arm_boot.c Log message: Optionally setup old style linux bootparams for -kernel, by Juergen Lock. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.321r2=1.322 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.256r2=1.257 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.7r2=1.8
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/08 01:57:57 Modified files: . : vl.c vl.h Log message: Don't refresh a graphical screen when it isn't displayed, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.304r2=1.305 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.249r2=1.250
[Qemu-devel] qemu vl.c vl.h hw/pxa.h hw/pxa2xx.c hw/pxa2xx_l...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/04/30 01:48:07 Modified files: . : vl.c vl.h hw : pxa.h pxa2xx.c Added files: hw : pxa2xx_lcd.c pxa2xx_mmci.c pxa2xx_pcmcia.c pxa2xx_template.h pxa2xx_timer.c Log message: Add remaining PXA2xx on-chip peripherals except I2C master. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.288r2=1.289 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.224r2=1.225 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_lcd.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_pcmcia.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_template.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_timer.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu vl.c vl.h ecc.h hw/nand.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/04/30 02:09:25 Modified files: . : vl.c vl.h Added files: . : ecc.h hw : nand.c Log message: NAND Flash memory emulation and ECC calculation helpers for use by NAND controllers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.289r2=1.290 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.225r2=1.226 http://cvs.savannah.gnu.org/viewcvs/qemu/ecc.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/nand.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/04/24 06:52:59 Modified files: . : vl.c vl.h Log message: Add -pflash option to register parallel flash bloc devices. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.283r2=1.284 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.218r2=1.219
[Qemu-devel] qemu vl.c vl.h hw/sun4m.c hw/tcx.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/04/21 19:45:49 Modified files: . : vl.c vl.h hw : sun4m.c tcx.c Log message: TCX 24 bit model support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.282r2=1.283 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.217r2=1.218 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu vl.c vl.h hw/sun4m.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir107/04/01 15:44:43 Modified files: . : vl.c vl.h hw : sun4m.c Log message: Reorganise Sun4m to allow other machine types CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.274r2=1.275 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.200r2=1.201 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.26r2=1.27 _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: [Qemu-devel] qemu vl.c vl.h hw/integratorcp.c hw/mips_malta....
On Mon, Mar 05, 2007 at 07:44:02PM +, Jocelyn Mayer wrote: Log message: New -cpu options: choose CPU model for emulated target. Only relevant on PowerPC targets, for now. I noticed that the usage still refers to -C instead of -cpu: Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.261 diff -u -r1.261 vl.c --- vl.c5 Mar 2007 19:44:01 - 1.261 +++ vl.c7 Mar 2007 12:43:49 - @@ -6355,7 +6355,7 @@ \n Standard options:\n -M machine select emulated machine (-M ? for list)\n - -cpu cpuselect CPU (-C ? for list)\n + -cpu cpuselect CPU (-cpu ? for list)\n -fda/-fdb file use 'file' as floppy disk 0/1 image\n -hda/-hdb file use 'file' as IDE hard disk 0/1 image\n -hdc/-hdd file use 'file' as IDE hard disk 2/3 image\n Cheers, -- Stuart Brady ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vl.h hw/integratorcp.c hw/realview.c ...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/03/08 03:04:12 Modified files: . : vl.c vl.h hw : integratorcp.c realview.c versatilepb.c linux-user : main.c target-arm : cpu.h helper.c Log message: Implement --cpu for ARM. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.261r2=1.262 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.192r2=1.193 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.101r2=1.102 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1=1.8r2=1.9 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vl.h hw/integratorcp.c hw/mips_malta....
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/03/05 19:44:02 Modified files: . : vl.c vl.h hw : integratorcp.c mips_malta.c mips_r4k.c pc.c ppc_chrp.c ppc_prep.c realview.c shix.c sun4m.c sun4u.c versatilepb.c Log message: New -cpu options: choose CPU model for emulated target. Only relevant on PowerPC targets, for now. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.260r2=1.261 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.190r2=1.191 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.70r2=1.71 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemur1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemur1=1.29r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.24r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.8r2=1.9 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vl.h hw/esp.c hw/sun4m.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/24 17:12:43 Modified files: . : vl.c vl.h hw : esp.c sun4m.c Log message: Fix SCSI cdrom boot, thanks Blue Swirl. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.228r2=1.229 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.159r2=1.160 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/esp.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.21r2=1.22 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/12 20:21:17 Modified files: . : vl.c vl.h Log message: win32 serial port support (initial patch by kazu CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.168tr2=1.169r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.107tr2=1.108r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./vl.c ./vl.h hw/lance.c hw/ne2000.c hw/sm...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/02/04 22:15:28 Modified files: . : vl.c vl.h hw : lance.c ne2000.c smc91c111.c Log message: Avoid buffer overflow when sending slirp packets. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.160tr2=1.161r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.100tr2=1.101r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/lance.c.diff?tr1=1.5tr2=1.6r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ne2000.c.diff?tr1=1.18tr2=1.19r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/smc91c111.c.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
