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 <tr...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
