[Qemu-devel] PreP kernels boot using Qemu

[Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

Hi all,

I've been investigating more about PreP kernel boot using Qemu and I
achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
unmodified OHW.
The issues I found in the kernel are:
- the OpenFirmware video console driver is broken in recent 2.4 kernels
and have been removed from recent 2.6 kernel
- I then decided to use the vga16fb console driver but needed to do some
patches in order to make it compile properly
- the CMOS RTC driver is not available for PPC architecture in 2.6
kernels and need some patches in order to be usable
- I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
kernels. The bugs are visible only when cross-compiling from a
little-endian and/or 64 bits host.
- I got issues (ie process freezing) when using the 2.6.22 kernel with
HZ > 100. It seems to run properly when the system timer is set to 100
Hz but this needs more tests for confirmation.
- I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
when it has no RTC available. There is no problem when the RTC is
present. This is likely to be a kernel bug: when no RTC is available, it
cannot calibrate its timers properly and the kernel timer seems to run
very fast. Forcing (with hacks...) the timer to run at nearly real-time
seems to prevent the bug to happen.

I then generated some kernels that allow me to boot and use those 3
kernels.
Here are 3 tarballs with:
- a patch to be applied to the vanilla kernel sources to fix the
mentionned bugs
- the .config file I used to build the kernel
- the zImage.prep image
<http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
<http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
<http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>

I then run Qemu with the following command line template:
./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
-cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
-kernel
<src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep

Hope this helps.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Jocelyn Mayer]

On Mon, 2007-10-22 at 09:36 +0200, J. Mayer wrote:
> Hi all,
> 
> I've been investigating more about PreP kernel boot using Qemu and I
> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> unmodified OHW.
> The issues I found in the kernel are:
> - the OpenFirmware video console driver is broken in recent 2.4 kernels
> and have been removed from recent 2.6 kernel
> - I then decided to use the vga16fb console driver but needed to do some
> patches in order to make it compile properly
> - the CMOS RTC driver is not available for PPC architecture in 2.6
> kernels and need some patches in order to be usable
> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> kernels. The bugs are visible only when cross-compiling from a
> little-endian and/or 64 bits host.
> - I got issues (ie process freezing) when using the 2.6.22 kernel with
> HZ > 100. It seems to run properly when the system timer is set to 100
> Hz but this needs more tests for confirmation.
> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> when it has no RTC available. There is no problem when the RTC is
> present. This is likely to be a kernel bug: when no RTC is available, it
> cannot calibrate its timers properly and the kernel timer seems to run
> very fast. Forcing (with hacks...) the timer to run at nearly real-time
> seems to prevent the bug to happen.
> 
> I then generated some kernels that allow me to boot and use those 3
> kernels.
> Here are 3 tarballs with:
> - a patch to be applied to the vanilla kernel sources to fix the
> mentionned bugs
> - the .config file I used to build the kernel
> - the zImage.prep image
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>
> 
> I then run Qemu with the following command line template:
> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> -cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
> -kernel
> <src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep
> 
> Hope this helps.

Two points I forgot:
- there is no way to make Qemu stop when the PreP kernel displays "Power
down" because the prep_halt routine just does an infinite loop.
- the board reset would not work with the current code. I will fix this
soon.


-- 
Jocelyn Mayer <l_indien@magic.fr>

Re: [Qemu-devel] PreP kernels boot using Qemu

[Rob Landley]

On Monday 22 October 2007 4:23:00 am Jocelyn Mayer wrote:
> > I then generated some kernels that allow me to boot and use those 3
> > kernels.
> > Here are 3 tarballs with:
> > - a patch to be applied to the vanilla kernel sources to fix the
> > mentionned bugs
> > - the .config file I used to build the kernel
> > - the zImage.prep image
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.ta
> >r.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.ta
> >r.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.ta
> >r.bz2>

The thing is, that's done with ARCH=ppc and the Linux kernel is migrating to 
ARCH=powerpc.  (This is apparently fallout from merging the 32-bit and 64-bit 
PowerPC architecture sources.)

ARCH=ppc is deprecated and going away some time next year, they're migrating 
everything over to the new infrastructure in ARCH=powerpc.

From an immediate practical standpoint, I can't use ARCH=ppc to build a system 
because that architecture doesn't support the "make headers_install" target 
so I can extract appropriate architecture-specific Linux kernel headers 
defining the system calls I can build a C library against.

There's a series of 20+ patches to add proper prep support to arch=powerpc, 
but when those are applied the result runs on real prep hardware but not 
under qemu (due to the prep residual data in qemu not matching the Linux 
kernel's expectations).

Rather than update the residual data qemu is generating so the linux kernel 
can parse it to add entries to a device tree, Milton just created a "qemu 
target" with the same set of hardware as a prep system but minus the boot 
logic.  Instead he created a  device tree data structure in the format Linux 
wants it, and a boot room that could feed that device tree to the Linux 
kernel directly.  This was much simpler and mostly involved removing code 
rather than adding any.

Getting the kernel to build a "qemu target" that runs on prep but doesn't have 
the prep packaging, boot wrapper, or residual data parsing logic, was 1 patch 
instead of 20+.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> Hi all,
> 
> I've been investigating more about PreP kernel boot using Qemu and I
> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> unmodified OHW.
> The issues I found in the kernel are:
> - the OpenFirmware video console driver is broken in recent 2.4 kernels
> and have been removed from recent 2.6 kernel
> - I then decided to use the vga16fb console driver but needed to do some
> patches in order to make it compile properly
> - the CMOS RTC driver is not available for PPC architecture in 2.6
> kernels and need some patches in order to be usable
> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> kernels. The bugs are visible only when cross-compiling from a
> little-endian and/or 64 bits host.
> - I got issues (ie process freezing) when using the 2.6.22 kernel with
> HZ > 100. It seems to run properly when the system timer is set to 100
> Hz but this needs more tests for confirmation.
> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> when it has no RTC available. There is no problem when the RTC is
> present. This is likely to be a kernel bug: when no RTC is available, it
> cannot calibrate its timers properly and the kernel timer seems to run
> very fast. Forcing (with hacks...) the timer to run at nearly real-time
> seems to prevent the bug to happen.
> 
> I then generated some kernels that allow me to boot and use those 3
> kernels.
> Here are 3 tarballs with:
> - a patch to be applied to the vanilla kernel sources to fix the
> mentionned bugs
> - the .config file I used to build the kernel
> - the zImage.prep image
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>
> 
> I then run Qemu with the following command line template:
> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> -cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
> -kernel
> <src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep
> 
> Hope this helps.
> 

Yes, this help a lot, thanks! With your config file, I have been able to
build and boot a 2.6.22 kernel. I have used a Debian sid chroot.

Here are a few remarks:
- The NE2000 card doesn't work for the same reason as with the powerpc
  architecture. The kernel patch below fixes the problem. I will send it
  later along with the ppc patch.
- The "floating point" problem I reported during the week-end does not
  exists, probably because of the switch from powerpc to ppc. I still 
  don't know if it is a kernel problem or a QEMU problem (or both).
- PCI is broken. PCI IDs are reported in the wrong endianness:
  00:00.0 Non-VGA unclassified device: Unknown device 0148:5710 (rev 06)
  00:01.0 Non-VGA unclassified device: Santa Cruz Operation Unknown device 3412 (rev 03)

Otherwise everything works fine for me, it looks a bit faster than 
MIPS(el) emulation (which is faster than ARM and SPARC). I still haven't 
done that much tests though.  


Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
index 1e5a00a..559f27c 100644
--- a/arch/ppc/syslib/i8259.c
+++ b/arch/ppc/syslib/i8259.c
@@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
 static struct irq_chip i8259_pic = {
 	.typename	= " i8259    ",
 	.mask		= i8259_mask_irq,
+	.disable	= i8259_mask_irq,
 	.unmask		= i8259_unmask_irq,
 	.mask_ack	= i8259_mask_and_ack_irq,
 };


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > Hi all,
> > 
> > I've been investigating more about PreP kernel boot using Qemu and I
> > achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > unmodified OHW.
> > The issues I found in the kernel are:
> > - the OpenFirmware video console driver is broken in recent 2.4 kernels
> > and have been removed from recent 2.6 kernel
> > - I then decided to use the vga16fb console driver but needed to do some
> > patches in order to make it compile properly
> > - the CMOS RTC driver is not available for PPC architecture in 2.6
> > kernels and need some patches in order to be usable
> > - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> > kernels. The bugs are visible only when cross-compiling from a
> > little-endian and/or 64 bits host.
> > - I got issues (ie process freezing) when using the 2.6.22 kernel with
> > HZ > 100. It seems to run properly when the system timer is set to 100
> > Hz but this needs more tests for confirmation.
> > - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> > when it has no RTC available. There is no problem when the RTC is
> > present. This is likely to be a kernel bug: when no RTC is available, it
> > cannot calibrate its timers properly and the kernel timer seems to run
> > very fast. Forcing (with hacks...) the timer to run at nearly real-time
> > seems to prevent the bug to happen.
> > 
> > I then generated some kernels that allow me to boot and use those 3
> > kernels.
> > Here are 3 tarballs with:
> > - a patch to be applied to the vanilla kernel sources to fix the
> > mentionned bugs
> > - the .config file I used to build the kernel
> > - the zImage.prep image
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>
> > 
> > I then run Qemu with the following command line template:
> > ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> > tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> > -cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
> > -kernel
> > <src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep
> > 
> > Hope this helps.
> > 
> 
> Yes, this help a lot, thanks! With your config file, I have been able to
> build and boot a 2.6.22 kernel. I have used a Debian sid chroot.
> 
> Here are a few remarks:
> - The NE2000 card doesn't work for the same reason as with the powerpc
>   architecture. The kernel patch below fixes the problem. I will send it
>   later along with the ppc patch.

There's something else strange with the PCI ethernet devices: they got
no IRQ assigned (as if the BIOS does not configure them properly). And
the RTL8139 never has a mac address, never detects the PHY link, then
there may be endianness issues in the emulation (I did not check at
all).

> - The "floating point" problem I reported during the week-end does not
>   exists, probably because of the switch from powerpc to ppc. I still 
>   don't know if it is a kernel problem or a QEMU problem (or both).

There may be issues with the floating point emulation, especially if
some kernel or programs relies on the FPSCR (floating-point status)
register which is never updated in Qemu.

> - PCI is broken. PCI IDs are reported in the wrong endianness:
>   00:00.0 Non-VGA unclassified device: Unknown device 0148:5710 (rev 06)
>   00:01.0 Non-VGA unclassified device: Santa Cruz Operation Unknown device 3412 (rev 03)

This does not happen with 2.4 kernels. Using the 2.4.35 image, all PCI
descriptors are OK and the drivers properly recognize the devices. What
I suspect is that 2.6 kernels tweak the chipset to make it handle the
endian-reverse accesses.

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

J. Mayer a écrit :
> On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
>> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
>>> Hi all,
>>>
>>> I've been investigating more about PreP kernel boot using Qemu and I
>>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
>>> unmodified OHW.
>>> The issues I found in the kernel are:
>>> - the OpenFirmware video console driver is broken in recent 2.4 kernels
>>> and have been removed from recent 2.6 kernel
>>> - I then decided to use the vga16fb console driver but needed to do some
>>> patches in order to make it compile properly
>>> - the CMOS RTC driver is not available for PPC architecture in 2.6
>>> kernels and need some patches in order to be usable
>>> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
>>> kernels. The bugs are visible only when cross-compiling from a
>>> little-endian and/or 64 bits host.
>>> - I got issues (ie process freezing) when using the 2.6.22 kernel with
>>> HZ > 100. It seems to run properly when the system timer is set to 100
>>> Hz but this needs more tests for confirmation.
>>> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
>>> when it has no RTC available. There is no problem when the RTC is
>>> present. This is likely to be a kernel bug: when no RTC is available, it
>>> cannot calibrate its timers properly and the kernel timer seems to run
>>> very fast. Forcing (with hacks...) the timer to run at nearly real-time
>>> seems to prevent the bug to happen.
>>>
>>> I then generated some kernels that allow me to boot and use those 3
>>> kernels.
>>> Here are 3 tarballs with:
>>> - a patch to be applied to the vanilla kernel sources to fix the
>>> mentionned bugs
>>> - the .config file I used to build the kernel
>>> - the zImage.prep image
>>> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
>>> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
>>> <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>
>>>
>>> I then run Qemu with the following command line template:
>>> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
>>> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
>>> -cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
>>> -kernel
>>> <src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep
>>>
>>> Hope this helps.
>>>
>> Yes, this help a lot, thanks! With your config file, I have been able to
>> build and boot a 2.6.22 kernel. I have used a Debian sid chroot.
>>
>> Here are a few remarks:
>> - The NE2000 card doesn't work for the same reason as with the powerpc
>>   architecture. The kernel patch below fixes the problem. I will send it
>>   later along with the ppc patch.
> 
> There's something else strange with the PCI ethernet devices: they got
> no IRQ assigned (as if the BIOS does not configure them properly). And
> the RTL8139 never has a mac address, never detects the PHY link, then
> there may be endianness issues in the emulation (I did not check at
> all).
> 
>> - The "floating point" problem I reported during the week-end does not
>>   exists, probably because of the switch from powerpc to ppc. I still 
>>   don't know if it is a kernel problem or a QEMU problem (or both).
> 
> There may be issues with the floating point emulation, especially if
> some kernel or programs relies on the FPSCR (floating-point status)
> register which is never updated in Qemu.
> 

Is there any technical reason behind that, or is it just a lack of time?


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> >>> Hi all,
> >>>
> >>> I've been investigating more about PreP kernel boot using Qemu and I
> >>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> >>> unmodified OHW.
[...]
> >> - The "floating point" problem I reported during the week-end does
> not
> >>   exists, probably because of the switch from powerpc to ppc. I
> still 
> >>   don't know if it is a kernel problem or a QEMU problem (or both).
> > 
> > There may be issues with the floating point emulation, especially if
> > some kernel or programs relies on the FPSCR (floating-point status)
> > register which is never updated in Qemu.
> > 
> 
> Is there any technical reason behind that, or is it just a lack of
> time?

I can say  both:
for most program, using floating point arithmetic ala "fast-math", it's
not necessary to maintain a precise FPU state, as those program will
never raise any FPU exception, never generate NaNs, infinites, ...
The other reason is that it would need to check every FPU insn arguments
and results at run time and treat all special cases following the actual
PowerPC implementations behavior if we want to get a precise emulation.
This behavior could be for example selected at compile time: then one
would have the choice to have a quick FPU emulation model or a precise
one.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Thiemo Seufer]

J. Mayer wrote:
> 
> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> > J. Mayer a écrit :
> > > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> > >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > >>> Hi all,
> > >>>
> > >>> I've been investigating more about PreP kernel boot using Qemu and I
> > >>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > >>> unmodified OHW.
> [...]
> > >> - The "floating point" problem I reported during the week-end does
> > not
> > >>   exists, probably because of the switch from powerpc to ppc. I
> > still 
> > >>   don't know if it is a kernel problem or a QEMU problem (or both).
> > > 
> > > There may be issues with the floating point emulation, especially if
> > > some kernel or programs relies on the FPSCR (floating-point status)
> > > register which is never updated in Qemu.
> > > 
> > 
> > Is there any technical reason behind that, or is it just a lack of
> > time?
> 
> I can say  both:
> for most program, using floating point arithmetic ala "fast-math", it's
> not necessary to maintain a precise FPU state, as those program will
> never raise any FPU exception, never generate NaNs, infinites, ...
> The other reason is that it would need to check every FPU insn arguments
> and results at run time and treat all special cases following the actual
> PowerPC implementations behavior if we want to get a precise emulation.
> This behavior could be for example selected at compile time: then one
> would have the choice to have a quick FPU emulation model or a precise
> one.

For mips I chose the middle ground: The emulation is architecturally
correct but may not reflect FPU behaviour of the specific silicon.
E.g. one effect is that in certain cases the emulation computes values
close to underflow, while real hardware would throw the (mips FPU
specific) unimplemented exception.

For most cases this should be good enough, since only specialized
software will rely on a specific implementation's oddities.


Thiemo

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > 
> > On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> > > J. Mayer a écrit :
> > > > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> > > >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> I've been investigating more about PreP kernel boot using Qemu and I
> > > >>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > > >>> unmodified OHW.
> > [...]
> > > >> - The "floating point" problem I reported during the week-end does
> > > not
> > > >>   exists, probably because of the switch from powerpc to ppc. I
> > > still 
> > > >>   don't know if it is a kernel problem or a QEMU problem (or both).
> > > > 
> > > > There may be issues with the floating point emulation, especially if
> > > > some kernel or programs relies on the FPSCR (floating-point status)
> > > > register which is never updated in Qemu.
> > > > 
> > > 
> > > Is there any technical reason behind that, or is it just a lack of
> > > time?
> > 
> > I can say  both:
> > for most program, using floating point arithmetic ala "fast-math", it's
> > not necessary to maintain a precise FPU state, as those program will
> > never raise any FPU exception, never generate NaNs, infinites, ...
> > The other reason is that it would need to check every FPU insn arguments
> > and results at run time and treat all special cases following the actual
> > PowerPC implementations behavior if we want to get a precise emulation.
> > This behavior could be for example selected at compile time: then one
> > would have the choice to have a quick FPU emulation model or a precise
> > one.
> 
> For mips I chose the middle ground: The emulation is architecturally
> correct but may not reflect FPU behaviour of the specific silicon.
> E.g. one effect is that in certain cases the emulation computes values
> close to underflow, while real hardware would throw the (mips FPU
> specific) unimplemented exception.
> 
> For most cases this should be good enough, since only specialized
> software will rely on a specific implementation's oddities.

Well, what you've done for Mips is exactly what I called the "precise
emulation" and is far slower than the "fast math" emulation I got for
PowerPC. I was wrong talking about "PowerPC implementations" when I
should have said "PowerPC specification"; but there should be no
difference between the two (or it's not a PowerPC CPU...) because the
POWER/PowerPC specification describes very precisely the behavior of the
FPU.
The "fast math" model relies on the native-softmmu code and is suficient
for most applications. But there are a few instructions that should
always take care (or maybe at least reset) the FPSCR register, which is
not done in the current code.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

J. Mayer a écrit :
> On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
>> J. Mayer wrote:
>>> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
>>>> J. Mayer a écrit :
>>>>> On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
>>>>>> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've been investigating more about PreP kernel boot using Qemu and I
>>>>>>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
>>>>>>> unmodified OHW.
>>> [...]
>>>>>> - The "floating point" problem I reported during the week-end does
>>>> not
>>>>>>   exists, probably because of the switch from powerpc to ppc. I
>>>> still 
>>>>>>   don't know if it is a kernel problem or a QEMU problem (or both).
>>>>> There may be issues with the floating point emulation, especially if
>>>>> some kernel or programs relies on the FPSCR (floating-point status)
>>>>> register which is never updated in Qemu.
>>>>>
>>>> Is there any technical reason behind that, or is it just a lack of
>>>> time?
>>> I can say  both:
>>> for most program, using floating point arithmetic ala "fast-math", it's
>>> not necessary to maintain a precise FPU state, as those program will
>>> never raise any FPU exception, never generate NaNs, infinites, ...
>>> The other reason is that it would need to check every FPU insn arguments
>>> and results at run time and treat all special cases following the actual
>>> PowerPC implementations behavior if we want to get a precise emulation.
>>> This behavior could be for example selected at compile time: then one
>>> would have the choice to have a quick FPU emulation model or a precise
>>> one.
>> For mips I chose the middle ground: The emulation is architecturally
>> correct but may not reflect FPU behaviour of the specific silicon.
>> E.g. one effect is that in certain cases the emulation computes values
>> close to underflow, while real hardware would throw the (mips FPU
>> specific) unimplemented exception.
>>
>> For most cases this should be good enough, since only specialized
>> software will rely on a specific implementation's oddities.
> 
> Well, what you've done for Mips is exactly what I called the "precise
> emulation" and is far slower than the "fast math" emulation I got for
> PowerPC. I was wrong talking about "PowerPC implementations" when I
> should have said "PowerPC specification"; but there should be no
> difference between the two (or it's not a PowerPC CPU...) because the
> POWER/PowerPC specification describes very precisely the behavior of the
> FPU.
> The "fast math" model relies on the native-softmmu code and is suficient
> for most applications. But there are a few instructions that should
> always take care (or maybe at least reset) the FPSCR register, which is
> not done in the current code.
> 

Then I guess it is what has been done on the SPARC target: after each FP
instruction, check_ieee_exceptions() is called to accumulate the IEEE
exceptions and generate real exceptions if they are enabled.

That doesn't look really complex, but I agree that could slow down a bit
the emulation. I will get a closer look in two or three weeks.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Tue, 2007-10-23 at 23:59 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> >> J. Mayer wrote:
> >>> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> >>>> J. Mayer a écrit :
> >>>>> On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> >>>>>> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I've been investigating more about PreP kernel boot using Qemu and I
> >>>>>>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> >>>>>>> unmodified OHW.
> >>> [...]
> >>>>>> - The "floating point" problem I reported during the week-end does
> >>>> not
> >>>>>>   exists, probably because of the switch from powerpc to ppc. I
> >>>> still 
> >>>>>>   don't know if it is a kernel problem or a QEMU problem (or both).
> >>>>> There may be issues with the floating point emulation, especially if
> >>>>> some kernel or programs relies on the FPSCR (floating-point status)
> >>>>> register which is never updated in Qemu.
> >>>>>
> >>>> Is there any technical reason behind that, or is it just a lack of
> >>>> time?
> >>> I can say  both:
> >>> for most program, using floating point arithmetic ala "fast-math", it's
> >>> not necessary to maintain a precise FPU state, as those program will
> >>> never raise any FPU exception, never generate NaNs, infinites, ...
> >>> The other reason is that it would need to check every FPU insn arguments
> >>> and results at run time and treat all special cases following the actual
> >>> PowerPC implementations behavior if we want to get a precise emulation.
> >>> This behavior could be for example selected at compile time: then one
> >>> would have the choice to have a quick FPU emulation model or a precise
> >>> one.
> >> For mips I chose the middle ground: The emulation is architecturally
> >> correct but may not reflect FPU behaviour of the specific silicon.
> >> E.g. one effect is that in certain cases the emulation computes values
> >> close to underflow, while real hardware would throw the (mips FPU
> >> specific) unimplemented exception.
> >>
> >> For most cases this should be good enough, since only specialized
> >> software will rely on a specific implementation's oddities.
> > 
> > Well, what you've done for Mips is exactly what I called the "precise
> > emulation" and is far slower than the "fast math" emulation I got for
> > PowerPC. I was wrong talking about "PowerPC implementations" when I
> > should have said "PowerPC specification"; but there should be no
> > difference between the two (or it's not a PowerPC CPU...) because the
> > POWER/PowerPC specification describes very precisely the behavior of the
> > FPU.
> > The "fast math" model relies on the native-softmmu code and is suficient
> > for most applications. But there are a few instructions that should
> > always take care (or maybe at least reset) the FPSCR register, which is
> > not done in the current code.
> > 
> 
> Then I guess it is what has been done on the SPARC target: after each FP
> instruction, check_ieee_exceptions() is called to accumulate the IEEE
> exceptions and generate real exceptions if they are enabled.
> 
> That doesn't look really complex, but I agree that could slow down a bit
> the emulation. I will get a closer look in two or three weeks.

It's not so complex. What would greatly slow down the emulation is that
you need to use the softfloat model instead of the softfloat-native one
for this to produce the expected result.
The PowerPC "fadd" instruction just compiles with 3 insns on amd64,
using the "fast math" model:
movlpd 0x1b8(%r14),%xmm0 ; /* Load env->ft0 into a MMX register */
addsd  0x1b0(%r14),%xmm0 ; /* Add env->ft1 */
movsd  %xmm0,0x1b0(%r14) ; /* Store the result into env->ft0 */
With the "precise" model, you need to:
1/ Clear the floating point flags
2/ Load operands from env->ft0 & env->ft1 into host registers
3/ Call the float64_add function
4/ Store the result into env->ft0
5/ Compute the architecture specific FPU flags
which will lead to execute much more code for each FPU operation and
will consume much more space in the TB buffer.

It's a good idea to allow the use of such a precise model, when you want
to use specific applications that rely on the FPU to properly handle
NaNs, infinities and properly generate exceptions. But, as it's not
needed by most applications, having a "fast math" model is also great to
have a quicker emulation. I said it would be great to allow the choice
of the model at compile time but it could in fact be choosen at
run-time, just tweaking the code translator (which should not lead to
any performance penalty for the "fast" model case) and compiling twice
the FPU micro-operations, once with the CONFIG_SOFTFLOAT defined, once
without. This way, the Qemu user could easily choose between "fast" or
"precise" models, just changing a switch on the command line.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Thiemo Seufer]

J. Mayer wrote:
[snip]
> > > I can say  both:
> > > for most program, using floating point arithmetic ala "fast-math", it's
> > > not necessary to maintain a precise FPU state, as those program will
> > > never raise any FPU exception, never generate NaNs, infinites, ...
> > > The other reason is that it would need to check every FPU insn arguments
> > > and results at run time and treat all special cases following the actual
> > > PowerPC implementations behavior if we want to get a precise emulation.
> > > This behavior could be for example selected at compile time: then one
> > > would have the choice to have a quick FPU emulation model or a precise
> > > one.
> > 
> > For mips I chose the middle ground: The emulation is architecturally
> > correct but may not reflect FPU behaviour of the specific silicon.
> > E.g. one effect is that in certain cases the emulation computes values
> > close to underflow, while real hardware would throw the (mips FPU
> > specific) unimplemented exception.
> > 
> > For most cases this should be good enough, since only specialized
> > software will rely on a specific implementation's oddities.
> 
> Well, what you've done for Mips is exactly what I called the "precise
> emulation" and is far slower than the "fast math" emulation I got for
> PowerPC. I was wrong talking about "PowerPC implementations" when I
> should have said "PowerPC specification"; but there should be no
> difference between the two (or it's not a PowerPC CPU...) because the
> POWER/PowerPC specification describes very precisely the behavior of the
> FPU.
>
> The "fast math" model relies on the native-softmmu code and is suficient
> for most applications. But there are a few instructions that should
> always take care (or maybe at least reset) the FPSCR register, which is
> not done in the current code.

My theory is that occasional FP users won't suffer from the performance
impact, and heavy FP users are likely to expect IEEE conformance. Thus
I gave priority to correctness.

Implementing a R8000-style fast FP mode sounds like fun, but for the
moment I have already enough unfinished bits and pieces in Qemu. :-)


Thiemo

Re: [Qemu-devel] PreP kernels boot using Qemu

[Rob Landley]

On Monday 22 October 2007 11:28:10 am Aurelien Jarno wrote:
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>
> diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
> index 1e5a00a..559f27c 100644
> --- a/arch/ppc/syslib/i8259.c
> +++ b/arch/ppc/syslib/i8259.c
> @@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
>  static struct irq_chip i8259_pic = {
>  	.typename	= " i8259    ",
>  	.mask		= i8259_mask_irq,
> +	.disable	= i8259_mask_irq,
>  	.unmask		= i8259_unmask_irq,
>  	.mask_ack	= i8259_mask_and_ack_irq,
>  };

Using mdm's qemu target platform and the 4k bios that supplies a device tree, 
I applied this but it didn't make any difference in the ne2k-pci adapter (not 
that I noticed).  It still doesn't bind to anything during bootup.  (There's 
no eth0.)

I also tried enabling the 8139too driver and telling qemu "-net 
nic,model=rtl8139 -net user" (which made arm work), and it goes:

> PCI: Probing PCI hardware
> Memory resource not set for host bridge 0
> PCI: Cannot allocate resource region 2 of PCI bridge 0
> PCI: can't move host bridge resource
> PCI: Cannot allocate resource region 0 of device 0000:00:0d.0
> PCI: Cannot allocate resource region 1 of device 0000:00:0d.0
...
> 8139too Fast Ethernet driver 0.9.28
> 8139too 0000:00:0d.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
> 8139too 0000:00:0d.0: Use the "8139cp" driver for improved performance and
> stability. 

And then there's an eth0, but it doesn't work.  I can assign an address to it 
but no matter what I try, no packets are sent and received (the packet 
transmit/receive/error counts never even go up, they stay at zero).

Am I doing something wrong?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

Rob Landley a écrit :
> On Monday 22 October 2007 11:28:10 am Aurelien Jarno wrote:
>> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>>
>> diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
>> index 1e5a00a..559f27c 100644
>> --- a/arch/ppc/syslib/i8259.c
>> +++ b/arch/ppc/syslib/i8259.c
>> @@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
>>  static struct irq_chip i8259_pic = {
>>  	.typename	= " i8259    ",
>>  	.mask		= i8259_mask_irq,
>> +	.disable	= i8259_mask_irq,
>>  	.unmask		= i8259_unmask_irq,
>>  	.mask_ack	= i8259_mask_and_ack_irq,
>>  };
> 
> Using mdm's qemu target platform and the 4k bios that supplies a device tree, 
> I applied this but it didn't make any difference in the ne2k-pci adapter (not 
> that I noticed).  It still doesn't bind to anything during bootup.  (There's 
> no eth0.)

You need this patch to get the *ISA* NE2000 card working, the PCI one
still doesn't work.

> I also tried enabling the 8139too driver and telling qemu "-net 
> nic,model=rtl8139 -net user" (which made arm work), and it goes:
> 
>> PCI: Probing PCI hardware
>> Memory resource not set for host bridge 0
>> PCI: Cannot allocate resource region 2 of PCI bridge 0
>> PCI: can't move host bridge resource
>> PCI: Cannot allocate resource region 0 of device 0000:00:0d.0
>> PCI: Cannot allocate resource region 1 of device 0000:00:0d.0
> ...
>> 8139too Fast Ethernet driver 0.9.28
>> 8139too 0000:00:0d.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
>> 8139too 0000:00:0d.0: Use the "8139cp" driver for improved performance and
>> stability. 
> 
> And then there's an eth0, but it doesn't work.  I can assign an address to it 
> but no matter what I try, no packets are sent and received (the packet 
> transmit/receive/error counts never even go up, they stay at zero).
> 

The PCI emulation is broken for this target, it has to be fixed first.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PreP kernels boot using Qemu

[Rob Landley]

On Saturday 27 October 2007 3:07:05 am Aurelien Jarno wrote:
> Rob Landley a écrit :
> > On Monday 22 October 2007 11:28:10 am Aurelien Jarno wrote:
> >> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> >>
> >> diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
> >> index 1e5a00a..559f27c 100644
> >> --- a/arch/ppc/syslib/i8259.c
> >> +++ b/arch/ppc/syslib/i8259.c
> >> @@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
> >>  static struct irq_chip i8259_pic = {
> >>  	.typename	= " i8259    ",
> >>  	.mask		= i8259_mask_irq,
> >> +	.disable	= i8259_mask_irq,
> >>  	.unmask		= i8259_unmask_irq,
> >>  	.mask_ack	= i8259_mask_and_ack_irq,
> >>  };
> >
> > Using mdm's qemu target platform and the 4k bios that supplies a device
> > tree, I applied this but it didn't make any difference in the ne2k-pci
> > adapter (not that I noticed).  It still doesn't bind to anything during
> > bootup.  (There's no eth0.)
>
> You need this patch to get the *ISA* NE2000 card working, the PCI one
> still doesn't work.

Hmmm, Milton's ppc_qemu patch forgot to add PPC_QEMU to the ISA dependency 
list along with PREP and CHRP.  Let's see, patch that, switch on the config 
symbol, build in that driver and...  Nope:

> ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
> Last modified Nov 1, 2000 by Paul Gortmaker
> NE*000 ethercard probe at 0x300: failed to detect IRQ line.

I still have no eth0.

I just confirmed that arch/powerpc/sysdev/i8259.c has:
static struct irq_chip i8259_pic = {
        .typename       = " i8259    ",
        .mask           = i8259_mask_irq,
        .disable        = i8259_mask_irq,
        .unmask         = i8259_unmask_irq,
        .mask_ack       = i8259_mask_and_ack_irq,
};

Since your patch was to /arch/ppc instead...

Any ideas?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

Rob Landley a écrit :
> On Saturday 27 October 2007 3:07:05 am Aurelien Jarno wrote:
>> Rob Landley a écrit :
>>> On Monday 22 October 2007 11:28:10 am Aurelien Jarno wrote:
>>>> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>>>>
>>>> diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
>>>> index 1e5a00a..559f27c 100644
>>>> --- a/arch/ppc/syslib/i8259.c
>>>> +++ b/arch/ppc/syslib/i8259.c
>>>> @@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
>>>>  static struct irq_chip i8259_pic = {
>>>>  	.typename	= " i8259    ",
>>>>  	.mask		= i8259_mask_irq,
>>>> +	.disable	= i8259_mask_irq,
>>>>  	.unmask		= i8259_unmask_irq,
>>>>  	.mask_ack	= i8259_mask_and_ack_irq,
>>>>  };
>>> Using mdm's qemu target platform and the 4k bios that supplies a device
>>> tree, I applied this but it didn't make any difference in the ne2k-pci
>>> adapter (not that I noticed).  It still doesn't bind to anything during
>>> bootup.  (There's no eth0.)
>> You need this patch to get the *ISA* NE2000 card working, the PCI one
>> still doesn't work.
> 
> Hmmm, Milton's ppc_qemu patch forgot to add PPC_QEMU to the ISA dependency 
> list along with PREP and CHRP.  Let's see, patch that, switch on the config 
> symbol, build in that driver and...  Nope:
> 
>> ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
>> Last modified Nov 1, 2000 by Paul Gortmaker
>> NE*000 ethercard probe at 0x300: failed to detect IRQ line.
> 
> I still have no eth0.

You have to build the NE2000 driver as a module, and pass irq=9 io=0x300
when loading it.

> I just confirmed that arch/powerpc/sysdev/i8259.c has:
> static struct irq_chip i8259_pic = {
>         .typename       = " i8259    ",
>         .mask           = i8259_mask_irq,
>         .disable        = i8259_mask_irq,
>         .unmask         = i8259_unmask_irq,
>         .mask_ack       = i8259_mask_and_ack_irq,
> };
> 
> Since your patch was to /arch/ppc instead...
> 

I have posted two patches, one for ppc and one for powerpc. I have send
both of them upstream

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PreP kernels boot using Qemu

[Rob Landley]

On Sunday 28 October 2007 4:29:15 am Aurelien Jarno wrote:
> Rob Landley a écrit :
> > On Saturday 27 October 2007 3:07:05 am Aurelien Jarno wrote:
> >> Rob Landley a écrit :
> >>> On Monday 22 October 2007 11:28:10 am Aurelien Jarno wrote:
> >>>> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> >>>>
> >>>> diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
> >>>> index 1e5a00a..559f27c 100644
> >>>> --- a/arch/ppc/syslib/i8259.c
> >>>> +++ b/arch/ppc/syslib/i8259.c
> >>>> @@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
> >>>>  static struct irq_chip i8259_pic = {
> >>>>  	.typename	= " i8259    ",
> >>>>  	.mask		= i8259_mask_irq,
> >>>> +	.disable	= i8259_mask_irq,
> >>>>  	.unmask		= i8259_unmask_irq,
> >>>>  	.mask_ack	= i8259_mask_and_ack_irq,
> >>>>  };
> >>>
> >>> Using mdm's qemu target platform and the 4k bios that supplies a device
> >>> tree, I applied this but it didn't make any difference in the ne2k-pci
> >>> adapter (not that I noticed).  It still doesn't bind to anything during
> >>> bootup.  (There's no eth0.)
> >>
> >> You need this patch to get the *ISA* NE2000 card working, the PCI one
> >> still doesn't work.
> >
> > Hmmm, Milton's ppc_qemu patch forgot to add PPC_QEMU to the ISA
> > dependency list along with PREP and CHRP.  Let's see, patch that, switch
> > on the config
> >
> > symbol, build in that driver and...  Nope:
> >> ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
> >> Last modified Nov 1, 2000 by Paul Gortmaker
> >> NE*000 ethercard probe at 0x300: failed to detect IRQ line.
> >
> > I still have no eth0.
>
> You have to build the NE2000 driver as a module, and pass irq=9 io=0x300
> when loading it.

Hmmm...  All the kernels I've built for this project are static.  In theory I 
can add "ne.irq=9" to the kernel command line, but in practice it doesn't 
seem to work.  Nor does ne.0.irq=9 or irq=9

However, when I hardwire "dev->irq=9;" into the source code, it does seem to 
work.  (Or at least I can ping qemu's virtual gateway.)

Off to read the kernel command line parsing logic...

Thanks,

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] PreP kernels boot using Qemu

[Ed Swierk]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On 10/28/07, Rob Landley <rob@landley.net> wrote:
> Hmmm...  All the kernels I've built for this project are static.  In theory I
> can add "ne.irq=9" to the kernel command line, but in practice it doesn't
> seem to work.  Nor does ne.0.irq=9 or irq=9
>
> However, when I hardwire "dev->irq=9;" into the source code, it does seem to
> work.  (Or at least I can ping qemu's virtual gateway.)
>
> Off to read the kernel command line parsing logic...

It seems that the driver.parameter syntax works only for parameters
that the driver exports in /sys/module/driver/parameters. The ne
driver doesn't define parameters at all when not compiled as a module,
let alone export them via sysfs.

The attached patch is my feeble attempt to remedy the situation. With
the patch, adding "ne.irq=9,10" to the kernel command line sets the
correct irqs for eth0 and eth1.

--Ed

[-- Attachment #2: linux-2.6.23-ne-module-params.patch --]
[-- Type: application/octet-stream, Size: 1718 bytes --]

Index: linux-2.6.23.1/drivers/net/Space.c
===================================================================
--- linux-2.6.23.1.orig/drivers/net/Space.c
+++ linux-2.6.23.1/drivers/net/Space.c
@@ -181,10 +181,6 @@ static struct devprobe2 isa_probes[] __i
 #ifdef CONFIG_E2100		/* Cabletron E21xx series. */
 	{e2100_probe, 0},
 #endif
-#if defined(CONFIG_NE2000) || \
-    defined(CONFIG_NE_H8300)  /* ISA (use ne2k-pci for PCI cards) */
-	{ne_probe, 0},
-#endif
 #ifdef CONFIG_LANCE		/* ISA/VLB (use pcnet32 for PCI cards) */
 	{lance_probe, 0},
 #endif
Index: linux-2.6.23.1/drivers/net/ne.c
===================================================================
--- linux-2.6.23.1.orig/drivers/net/ne.c
+++ linux-2.6.23.1/drivers/net/ne.c
@@ -888,16 +888,15 @@ static void __exit ne_exit(void)
 	platform_driver_unregister(&ne_driver);
 }
 
-#ifdef MODULE
 #define MAX_NE_CARDS	4	/* Max number of NE cards per module */
 static struct net_device *dev_ne[MAX_NE_CARDS];
 static int io[MAX_NE_CARDS];
 static int irq[MAX_NE_CARDS];
 static int bad[MAX_NE_CARDS];	/* 0xbad = bad sig or no reset ack */
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
-module_param_array(bad, int, NULL, 0);
+module_param_array(io, int, NULL, 0644);
+module_param_array(irq, int, NULL, 0644);
+module_param_array(bad, int, NULL, 0644);
 MODULE_PARM_DESC(io, "I/O base address(es),required");
 MODULE_PARM_DESC(irq, "IRQ number(s)");
 MODULE_PARM_DESC(bad, "Accept card(s) with bad signatures");
@@ -962,7 +961,6 @@ void __exit cleanup_module(void)
 		}
 	}
 }
-#else /* MODULE */
-module_init(ne_init);
-module_exit(ne_exit);
-#endif /* MODULE */
+
+module_init(init_module);
+module_exit(cleanup_module);