On Tue, Oct 18, 2016 at 9:35 PM, Tom Rini <tr...@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 <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.
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
U-Boot mailing list