-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/28/2014 05:02 PM, Christoffer Dall wrote:
> On Fri, Mar 28, 2014 at 04:08:52PM -0400, Michael Casadevall
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>>
>>
>> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
>>> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>>
>>>>
>>>> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
>>>>> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael
>>>>> Casadevall wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>
>>>>>> As I've made a fair bit of headway since LinaroConnect,
>>>>>> I wanted to drop a line on my current progress with
>>>>>> porting TianoCore to KVM
>>>>>>
>>>>>> Summary (tl;dr version):
>>>>>>
>>>>>> KVM can start TianoCore, and boot all the way to shell,
>>>>>> and access HDDs via VirtioBlk. We can start grub and
>>>>>> successfully retrieve files from ext partitions, load a
>>>>>> device tree, and start the kernel. The kernel runs
>>>>>> through most of the EFI stub, but falls over during
>>>>>> ExitBootServices()
>>>>>
>>>>> Thanks for providing this status!
>>>>>
>>>>>>
>>>>>> Long Version:
>>>>>>
>>>>>> So, after much blood sweat and tears, we're finally at
>>>>>> the point of trying to actually start a kernel, though
>>>>>> this (for the moment) remains an elusive goal. The
>>>>>> current problem is that once we call EBS(), we get an
>>>>>> exception from EFI with no Image information, which means
>>>>>> the exception handler doesn't know where it came from.
>>>>>> After several seconds, we get a second exception from
>>>>>> within DxeCore, and then EFI falls over.
>>>>>>
>>>>>> Debugging EFI is difficult and error prone, combined with
>>>>>> limited debug facilities from the gdb-stub in QEMU (no
>>>>>> breakpoints), and no decent way to load all of EFI
>>>>>> itself (you have to run add-symbol-file manually with the
>>>>>> output of commands printed on the console; supposedly its
>>>>>> possible to generate a giant GdbSyms.dll file to import
>>>>>> in a single go, but I haven't succeeded at this). This is
>>>>>> further complicated that it appears we're asserting
>>>>>> somewhere in a driver, and short of adding printfs to
>>>>>> *every* driver, its impossible to know which is
>>>>>> asseting.
>>>>>
>>>>> Maybe it's worth adding a hack-support-gdb-in-kvm
>>>>> implementation for this. If we go down this road, I can
>>>>> probably find time to help you out there.
>>>>>
>>>>> Can you do some scripting to replace assert statements with
>>>>> "{ print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }"
>>>>> type hack?
>>>>>
>>>>
>>>> That's probably a decent idea if I can find where ASSERT()
>>>> is defined. I'll try that in a bit.
>>>>
>>>>>>
>>>>>> Previous attempts to debug assets shows that EFI does
>>>>>> "odd" things to the stack when we hit an exception,
>>>>>> making walking it with GDB impossible. I need to figure
>>>>>> out what madness EFI does with my SP so I can get the
>>>>>> entire stack on an explosion, but this remains at best
>>>>>> hopeful thinking.
>>>>>
>>>>> This sounds very strange - could it be that because you
>>>>> take an exception, you use a SP from a different mode and
>>>>> everything just messes up?
>>>>>
>>>>
>>>> This could be GDB just being unhappy. I've had issues
>>>> walking the stack in KVM in general, but even if I walk the
>>>> stack by hand, I don't see a pointer to the next frame when
>>>> we're in an exception. To my knowledge, UEFI uses the
>>>> standard AArch64 C ABI, but this might be a faulty exception
>>>> on my part.
>>>>
>>>>>>
>>>>>> Further complicating things is that during EBS, my print
>>>>>> debugging goes away. I might just cheat and roll a
>>>>>> simple assembly function to bang out messages through
>>>>>> serial without calling anything else. Ugly as sin, but
>>>>>> this should let me get useful debug output through the
>>>>>> EBS framework. Complicating matters is that I need to
>>>>>> locate each and all EBS() event functions, which are
>>>>>> spread *everywhere* in TianoCore, and then debug them
>>>>>> each individually.
>>>>>
>>>>> I'm a little confused no knowing UEFI, is EBS() not a
>>>>> single function and what does it matter that it's called
>>>>> from multiple places?
>>>>>
>>>>
>>>> So, drivers and applications can enlist to get notification
>>>> of when ExitBootServices are called. This pushes a pointer to
>>>> a function into an array when is then iterated through and
>>>> this pointer is then called so drivers can unregister
>>>> themselves from boot services, etc.
>>>>
>>>> Complicating the issue is I can't use printf once
>>>> GetMemoryMap() is called without breaking EBS() (I think this
>>>> is a bug in UEFI, leif, 2 cents?, but I think I can twiddle
>>>> the serial port directly without breaking shit.
>>>
>>> yeah, just writing to the pl011 out should be trivial, or add
>>> an hvc temporary hack to KVM, I've done things like that when
>>> originally debugging kernel boot under KVM.
>>>
>>
>> Just for the record, hvc?
>>
>
> Hypervisor Call, 'HVC' is the instruction that causes a trap to
> KVM, so you could do "mov r1, #0x41; mov r0, #0xff42; hvc #0;" to
> invent a hypercall on number 0xff42 meaning "do print somewhere"
> and print 'A'. That would be useful if you don't know what your
> memory map is like and have no idea if you can even get to your
> pl011 registers, but if know the address of that, it may be much
> easier to just hardcode that.
>
>>>>
>>>> Having slept on it, its probably easy to print out the
>>>> pointers as we go through them, so I can get an idea of whats
>>>> listening for EBS and try and narrow down my list of
>>>> candidates.
>>>>
>>>
>>> yes, add a function that side-steps all the UEFI-weirdness
>>> (should be a few lines static function) that can print the
>>> pointers of the functions you're calling.
>>>
>>
>> Biggest issue is now binutils doesn't like PE?AArch64 files
>> (addr2line and friends don't work) but I think I can muddle
>> through it. There are tricks at this point I can use if I have a
>> pointer to get an idea where UEFI is.
>>
>>>>>>
>>>>>> I'm open to ideas on how best to accomplish this.
>>>>>>
>>>>>> On a larger scale, there are a couple of other bugs and
>>>>>> odds and ends which currently affect us:
>>>>>>
>>>>>> * wfi doesn't work
>>>>>>
>>>>>> THis is probably the biggest w.r.t. to functionality
>>>>>> that should work, but doesn't. The EFI event loop is
>>>>>> built on checking the timer, then calling wfi to check
>>>>>> the timer later. The problem here is we call wfi ... and
>>>>>> UEFI never comes back despite events firing (I can put
>>>>>> print code in the interrupt handler to confirm this).
>>>>>> This may be related to the VGIC errors I get running kvm
>>>>>> under foundation, but haven't taken the time to properly
>>>>>> nail down the bug here.
>>>>>
>>>>> So if I understand it, the expected sequence of events
>>>>> are:
>>>>>
>>>>> 1. check timer (arch timer counter?) 2. WFI 3. virtual
>>>>> arch timer interrupt, causes wake-up from WFI 4. go to 1->
>>>>>
>>>>> But you seem to get stuck at (2)?
>>>>>
>>>>
>>>> Exactly.
>>>>
>>>>> When you say "print code in the interrupt handler" is that
>>>>> the UEFI interrupt handler? In that case, you do wake up
>>>>> from the WFI...?
>>>>>
>>>>
>>>> I put a DEBUG print line in the Timer interrupt handler,
>>>> which prints out a message every tick letting me know the
>>>> timer was working. When we call wfi, the timer ticks still
>>>> show up (and I can see them through vgic with debugging there
>>>> enabled)
>>>>
>>>
>>> Which timer interrupt handler? The UEFI one?
>>>
>>> If you get an interrupt for the timer in UEFI, then your WFIs
>>> are not hanging, the VCPU actually resumes. Assuming you
>>> receive the interrupts on the same CPU that did the WFI.
>>>
>>
>> We're running uni-proc as that's all KVM supports ATM. What
>> happens is we wfi, the interrupt fires, the interrupt handler
>> fires, and we remain at the wfi.
>>
>
> again, which interrupt handler?
>
> If the one in UEFI, it sounds like you're problem is not that
> you're stuck at WFI, but that you re-execute WFI.
>
The one in EFI, and I suspect thats the case, we re-execute wfi.
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTNeSzAAoJEGKVRgSEnX1QNHwH/RXJeAR4CGn19bMBrnDLuDBD
Llm04GcMKHt3Vl0ltg76lqPh6kBav/pFSdIn3APb0dEU9G7L1UWyegAOCkImYL0E
5jACynkUVd4Hl1CEG2TMth2uWGXA326FZfTm115TWVuYKUJKA4ivfTy4jX/E8Yz8
9HvtO1rCo2Fw8ZmUHNthkembkFilm/Y4EimmfMC1zvR0E/SEe5W40QaI8Pjtcz52
xqi8HtBiZuwXnzIsa/Cag2D8N9+iU1/nI/S9HXeqaeUAUvGsVXeG9tBpMYgiEFvR
PIsIw9ivxkwNFXRjeNnGQf2X6WWCsbEdqFuFE5cXd4BNqVaFU/stRKJCicKGeBI=
=70SB
-----END PGP SIGNATURE-----
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
