From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 19 Oct 2016 08:03:40 -0400 Subject: [U-Boot] qemu-x86 issues In-Reply-To: References: <20161014233235.GB18591@bill-the-cat> <20161018131959.GZ18591@bill-the-cat> <20161018133554.GA18591@bill-the-cat> Message-ID: <20161019120340.GO18591@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 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: