All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] qemu-x86 issues
@ 2016-10-14 23:32 Tom Rini
  2016-10-18  2:36 ` Bin Meng
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Rini @ 2016-10-14 23:32 UTC (permalink / raw)
  To: u-boot

Hey guys,

After making Stephen's scripts work with qemu today, I've started
testing out what platforms I can test out via qemu.  I've found two
problems with qemu-x86.  First, there's a real problem with the network.
I run qemu with "-nographic -cpu qemu32 -netdev
user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
tftpboot things in and I'm getting crc32 mismatches.

Second, the sleep command is not at all accurate.  It's returning the 3
second test in less than 1 second.

Any ideas, or places I should try poking to solve these issues?  I'm
going to kludge around this for now by disabling these tests locally.
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161014/874257df/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-14 23:32 [U-Boot] qemu-x86 issues Tom Rini
@ 2016-10-18  2:36 ` Bin Meng
  2016-10-18 13:19   ` Tom Rini
  0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2016-10-18  2:36 UTC (permalink / raw)
  To: u-boot

Hi Tom,

On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini <trini@konsulko.com> wrote:
> Hey guys,
>
> After making Stephen's scripts work with qemu today, I've started
> testing out what platforms I can test out via qemu.  I've found two
> problems with qemu-x86.  First, there's a real problem with the network.
> I run qemu with "-nographic -cpu qemu32 -netdev
> user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> tftpboot things in and I'm getting crc32 mismatches.
>

I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
but did not see such issue.

> Second, the sleep command is not at all accurate.  It's returning the 3
> second test in less than 1 second.

Typical emulation target issue :) Did you see similar issue on other
QEMU platform with U-Boot?

>
> Any ideas, or places I should try poking to solve these issues?  I'm
> going to kludge around this for now by disabling these tests locally.
> Thanks!
>

Regards,
Bin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-18  2:36 ` Bin Meng
@ 2016-10-18 13:19   ` Tom Rini
  2016-10-18 13:35     ` Tom Rini
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Rini @ 2016-10-18 13:19 UTC (permalink / raw)
  To: u-boot

On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini <trini@konsulko.com> wrote:
> > Hey guys,
> >
> > After making Stephen's scripts work with qemu today, I've started
> > testing out what platforms I can test out via qemu.  I've found two
> > problems with qemu-x86.  First, there's a real problem with the network.
> > I run qemu with "-nographic -cpu qemu32 -netdev
> > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> > tftpboot things in and I'm getting crc32 mismatches.
> >
> 
> I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
> but did not see such issue.

Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
and the tests default to 0x0 if you don't provide an address rather than
$loadaddr.  I'll see about changing the tests.

> > Second, the sleep command is not at all accurate.  It's returning the 3
> > second test in less than 1 second.
> 
> Typical emulation target issue :) Did you see similar issue on other
> QEMU platform with U-Boot?

So this one is interesting.  I see the same failure for MIPS/PPC for the
qemu targets we have as well.  I don't see this under QEMU for the ARM
targets that I'm emulating.  I suspect there's some common problem on
the U-Boot side as also don't see this on the VMs I have running under
qemu nor when I boot the kernelci rootfs from U-Boot.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161018/b48c198b/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-18 13:19   ` Tom Rini
@ 2016-10-18 13:35     ` Tom Rini
  2016-10-19  3:18       ` Bin Meng
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Rini @ 2016-10-18 13:35 UTC (permalink / raw)
  To: u-boot

On Tue, Oct 18, 2016 at 09:19:59AM -0400, Tom Rini wrote:
> On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
> > Hi Tom,
> > 
> > On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini <trini@konsulko.com> wrote:
> > > Hey guys,
> > >
> > > After making Stephen's scripts work with qemu today, I've started
> > > testing out what platforms I can test out via qemu.  I've found two
> > > problems with qemu-x86.  First, there's a real problem with the network.
> > > I run qemu with "-nographic -cpu qemu32 -netdev
> > > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> > > tftpboot things in and I'm getting crc32 mismatches.
> > >
> > 
> > I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
> > but did not see such issue.
> 
> Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
> and the tests default to 0x0 if you don't provide an address rather than
> $loadaddr.  I'll see about changing the tests.
> 
> > > Second, the sleep command is not at all accurate.  It's returning the 3
> > > second test in less than 1 second.
> > 
> > Typical emulation target issue :) Did you see similar issue on other
> > QEMU platform with U-Boot?
> 
> So this one is interesting.  I see the same failure for MIPS/PPC for the
> qemu targets we have as well.  I don't see this under QEMU for the ARM
> targets that I'm emulating.  I suspect there's some common problem on
> the U-Boot side as also don't see this on the VMs I have running under
> qemu nor when I boot the kernelci rootfs from U-Boot.

Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
slightly too long.  x86 is the only one where it's just way too fast.
But this is not true once Linux itself is up.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161018/92078483/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-18 13:35     ` Tom Rini
@ 2016-10-19  3:18       ` Bin Meng
  2016-10-19 12:03         ` Tom Rini
  2016-12-03 11:09         ` Pavel Machek
  0 siblings, 2 replies; 7+ messages in thread
From: Bin Meng @ 2016-10-19  3:18 UTC (permalink / raw)
  To: u-boot

Hi Tom,

On Tue, Oct 18, 2016 at 9:35 PM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Oct 18, 2016 at 09:19:59AM -0400, Tom Rini wrote:
>> On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
>> > Hi Tom,
>> >
>> > On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini <trini@konsulko.com> wrote:
>> > > Hey guys,
>> > >
>> > > After making Stephen's scripts work with qemu today, I've started
>> > > testing out what platforms I can test out via qemu.  I've found two
>> > > problems with qemu-x86.  First, there's a real problem with the network.
>> > > I run qemu with "-nographic -cpu qemu32 -netdev
>> > > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
>> > > tftpboot things in and I'm getting crc32 mismatches.
>> > >
>> >
>> > I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
>> > but did not see such issue.
>>
>> Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
>> and the tests default to 0x0 if you don't provide an address rather than
>> $loadaddr.  I'll see about changing the tests.
>>
>> > > Second, the sleep command is not at all accurate.  It's returning the 3
>> > > second test in less than 1 second.
>> >
>> > Typical emulation target issue :) Did you see similar issue on other
>> > QEMU platform with U-Boot?
>>
>> So this one is interesting.  I see the same failure for MIPS/PPC for the
>> qemu targets we have as well.  I don't see this under QEMU for the ARM
>> targets that I'm emulating.  I suspect there's some common problem on
>> the U-Boot side as also don't see this on the VMs I have running under
>> qemu nor when I boot the kernelci rootfs from U-Boot.
>
> Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
> slightly too long.  x86 is the only one where it's just way too fast.
> But this is not true once Linux itself is up.
>

U-Boot uses x86 TSC timer as the delay timer. Right now the timer
frequency is hard-coded in device tree. Auto-calibration does not work
on QEMU. I need have another check to see if we can do
auto-calibration.

Regards,
Bin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-19  3:18       ` Bin Meng
@ 2016-10-19 12:03         ` Tom Rini
  2016-12-03 11:09         ` Pavel Machek
  1 sibling, 0 replies; 7+ messages in thread
From: Tom Rini @ 2016-10-19 12:03 UTC (permalink / raw)
  To: u-boot

On Wed, Oct 19, 2016 at 11:18:00AM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Tue, Oct 18, 2016 at 9:35 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Tue, Oct 18, 2016 at 09:19:59AM -0400, Tom Rini wrote:
> >> On Tue, Oct 18, 2016 at 10:36:41AM +0800, Bin Meng wrote:
> >> > Hi Tom,
> >> >
> >> > On Sat, Oct 15, 2016 at 7:32 AM, Tom Rini <trini@konsulko.com> wrote:
> >> > > Hey guys,
> >> > >
> >> > > After making Stephen's scripts work with qemu today, I've started
> >> > > testing out what platforms I can test out via qemu.  I've found two
> >> > > problems with qemu-x86.  First, there's a real problem with the network.
> >> > > I run qemu with "-nographic -cpu qemu32 -netdev
> >> > > user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
> >> > > tftpboot things in and I'm getting crc32 mismatches.
> >> > >
> >> >
> >> > I just tried QEMU v2.6.1 with u-boot.rom built from the master head,
> >> > but did not see such issue.
> >>
> >> Ah, I think I see it now.  We can't use 0x0 as where to load stuff to
> >> and the tests default to 0x0 if you don't provide an address rather than
> >> $loadaddr.  I'll see about changing the tests.
> >>
> >> > > Second, the sleep command is not at all accurate.  It's returning the 3
> >> > > second test in less than 1 second.
> >> >
> >> > Typical emulation target issue :) Did you see similar issue on other
> >> > QEMU platform with U-Boot?
> >>
> >> So this one is interesting.  I see the same failure for MIPS/PPC for the
> >> qemu targets we have as well.  I don't see this under QEMU for the ARM
> >> targets that I'm emulating.  I suspect there's some common problem on
> >> the U-Boot side as also don't see this on the VMs I have running under
> >> qemu nor when I boot the kernelci rootfs from U-Boot.
> >
> > Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
> > slightly too long.  x86 is the only one where it's just way too fast.
> > But this is not true once Linux itself is up.
> >
> 
> U-Boot uses x86 TSC timer as the delay timer. Right now the timer
> frequency is hard-coded in device tree. Auto-calibration does not work
> on QEMU. I need have another check to see if we can do
> auto-calibration.

OK, thanks.  So long as the problem is known it's not a high priority
thing, esp if you're sure it's not going to cascade to problems
elsewhere.  I just use -k 'not sleep' in my jenkins job now.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161019/58837ef7/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] qemu-x86 issues
  2016-10-19  3:18       ` Bin Meng
  2016-10-19 12:03         ` Tom Rini
@ 2016-12-03 11:09         ` Pavel Machek
  1 sibling, 0 replies; 7+ messages in thread
From: Pavel Machek @ 2016-12-03 11:09 UTC (permalink / raw)
  To: u-boot

Hi!

> > Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
> > slightly too long.  x86 is the only one where it's just way too fast.
> > But this is not true once Linux itself is up.
> >
> 
> U-Boot uses x86 TSC timer as the delay timer. Right now the timer
> frequency is hard-coded in device tree. Auto-calibration does not work
> on QEMU. I need have another check to see if we can do
> auto-calibration.

TSC is not really suitable for delays on x86. (Actually, TSC is pretty
much not suitable for anything :-) ). PIT should be easy to use and
work everywhere...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161203/7539cc6f/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-12-03 11:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-14 23:32 [U-Boot] qemu-x86 issues Tom Rini
2016-10-18  2:36 ` Bin Meng
2016-10-18 13:19   ` Tom Rini
2016-10-18 13:35     ` Tom Rini
2016-10-19  3:18       ` Bin Meng
2016-10-19 12:03         ` Tom Rini
2016-12-03 11:09         ` Pavel Machek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.